Control who can view, edit, and manage specific parts of a case using granular role-based access control (RBAC).
When to use granular permissions
By default, Cases uses broad permissions — "Editors" and "Case managers" can perform most actions, while "Viewers" have read-only access. Granular RBAC lets you go further by controlling access to individual case components like comments, attachments, fields, and status transitions.
🪄Tip
Use granular permissions when you need to:
Restrict sensitive case data to specific team members
Create specialized roles (e.g., a triage analyst who can update status but not delete cases)
Enforce least-privilege access across large teams
Protect fields marked as sensitive from broad visibility
How it works
Cases permissions operate at two levels:
Broad permissions: "Manage cases" and "Read cases" control overall case access. Manage cases bypasses all granular checks.
Granular permissions: Individual read and write permissions for each case component (comments, files, fields, status, etc.).
⚠️Warning
Permissions are non-cumulative. A higher-level action does not imply lower ones. For example, "Write comments" does not automatically grant "View comments". You must assign both explicitly.
Default team roles
Editors and case managers share the same Cases write permissions. The difference is that editors also have access to stories and credentials, while case managers are scoped exclusively to Cases.
Permissions reference
Core case operations
Case details
Case content
Case interaction sidebar
Interacting with components in the cases sidebar
Case search and filtering
Using the case search and filter view:
Case Templates
Metadata & Records
Team case settings
Updating the settings within each team specific to cases:
Permissions not granted to any default role
The following permissions are only available to team admins or through custom roles:
Delete cases — permanently delete cases
View sensitive information — view fields marked as sensitive
Update case security settings — update team-level case security settings
Best practices
Start with default roles, then customize. Default roles cover most use cases. Only create custom roles when you need to restrict or extend specific permissions.
Reserve Delete cases for admin-level custom roles. Deletion is irreversible — keep it tightly controlled.
Audit custom roles periodically. As your team grows, review whether custom role assignments still reflect actual responsibilities.
Remember permissions are non-cumulative. Always pair write permissions with their corresponding read permissions, or users may be able to create data they cannot view.
Learn more about custom roles
See custom roles for additional details on defining custom roles.