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

Review impact

Pay special attention to permissions that affect users, security, integrations, organization settings, or shared content.
6

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.

​
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.
  • 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.
  • Security review identifies stale access.
  • You consolidate duplicate roles.
Use Security Center and Users, groups, and roles as part of access review.