Role design principles
Good roles are:- Named for job responsibility.
- Easy to explain.
- Narrow enough to review.
- Broad enough to avoid one-off exceptions for every user.
- Reviewed when features, teams, or responsibilities change.
Create or edit a role
1
Open Role Management
Go to Users and choose Manage Roles.
2
Create or open a role
Click New Role or open an existing role.
3
Name the role
Use a clear name such as
QA reviewer, Workspace owner, or Integration admin.4
Select permissions
Choose only the permissions needed for the role’s work.
5
Configure security policy
Set any role-specific passkey or idle auto logout controls.
6
Review impact
Pay special attention to permissions that affect users, security, integrations, organization settings, or shared content.
7
Save and test
Save the role and verify expected access with a representative user.
Permission review questions
Ask these questions before granting access:- Does this role need to view the area?
- Does this role need to create or edit content there?
- Does this role need to delete or archive content?
- Does this role need to manage other users?
- Does this role need to configure organization settings?
- Does this role need connected app administration?
- Does this role need Security Center access?
Orchestration sharing and publishing
Orchestration sharing can be controlled through organization settings and role permissions.
Use Publisher when the user owns reusable workflows and also needs other publishing capabilities. Create a custom role with Share Orchestrations when the user should only manage collaborator access for owned Orchestrations.
For the full setup workflow, see Orchestration sharing controls.
Role security policy
Each role can have its own security policy. Use these controls when different user groups need different sign-in or session requirements.
Idle auto logout can use presets such as
15m, 30m, 1h, 4h, 8h, and 24h. Custom values must be between 15 minutes and 24 hours.
System roles cannot be renamed, deleted, or have their permission set changed from Role Management. Administrators can still update the role security policy for system roles when they have permission to edit roles.
Privileged roles
A privileged role can affect other users, security, organization settings, or connected app behavior. Privileged roles should usually:- Have a named owner.
- Require passkeys if your organization uses that policy.
- Use stricter magic-link or idle auto logout controls when your identity policy requires them.
- Be assigned to a small number of users.
- Be reviewed on a regular cadence.
- Be removed when the user no longer needs the access.
Roles versus Workspace membership
Roles control product capabilities. Workspace membership controls access to a specific Workspace. Example:
If a user has the right role but cannot see a project, check Workspace membership.
Role maintenance
Review roles when:- A new feature is enabled.
- An admin leaves or changes responsibility.
- A group starts using Sofie differently.
- A passkey policy changes.
- A magic-link or idle auto logout policy changes.
- Security review identifies stale access.
- You consolidate duplicate roles.