Skip to main content
Roles define what users can do in Sofie. A role is a reusable access package. Permissions inside the role control specific areas and actions. Use roles when you need consistent access for people with similar responsibilities.

​
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.
Avoid roles that are named after people, temporary projects, or vague seniority.

​
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?
If the answer is uncertain, start narrower.

​
Orchestration sharing and publishing

Orchestration sharing can be controlled through organization settings and role permissions.
Permission or roleUse it for
Share OrchestrationsLet a user share owned Orchestrations when unrestricted sharing is off.
Publish OrchestrationsLet a user publish owned Orchestrations to the organization.
PublisherGrant operational publishing access, including Orchestration sharing and publishing.
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.
ControlWhat it does
Require users to enroll a passkeyRequires users in the role to set up a passkey before using Sofie normally.
Require passkey after magic-link sign-inRequires a passkey challenge after magic-link sign-in for users in the role. Users without a passkey are sent to Account > Security to enroll one.
Idle auto logoutSigns users out after inactivity for the role. Leave it Off to use the current default session behavior.
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.
Role security policy changes can affect users immediately. Before requiring passkeys or shortening idle time, confirm affected users know how to sign in and have a supported passkey option.

​
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.
Do not grant privileged access just to solve a temporary content-access issue. Use Workspace membership, sharing, or a narrower role when possible.

​
Roles versus Workspace membership

Roles control product capabilities. Workspace membership controls access to a specific Workspace. Example:
NeedUse
User can create WorkspacesRole permission.
User can access one project WorkspaceWorkspace membership.
User can manage all usersAdmin role permission.
User can review one CoDraftShare the CoDraft or Workspace.
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.
Use Security Center and Users, groups, and roles as part of access review.