> ## Documentation Index
> Fetch the complete documentation index at: https://sofiedocs.usetransfer.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles and permissions

> Design Sofie roles, review permissions, and manage privileged access carefully.

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

<Steps>
  <Step title="Open Role Management">
    Go to **Users** and choose **Manage Roles**.
  </Step>

  <Step title="Create or open a role">
    Click **New Role** or open an existing role.
  </Step>

  <Step title="Name the role">
    Use a clear name such as `QA reviewer`, `Workspace owner`, or `Integration admin`.
  </Step>

  <Step title="Select permissions">
    Choose only the permissions needed for the role’s work.
  </Step>

  <Step title="Configure security policy">
    Set any role-specific passkey or idle auto logout controls.
  </Step>

  <Step title="Review impact">
    Pay special attention to permissions that affect users, security, integrations, organization settings, or shared content.
  </Step>

  <Step title="Save and test">
    Save the role and verify expected access with a representative user.
  </Step>
</Steps>

## 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 role         | Use it for                                                                           |
| -------------------------- | ------------------------------------------------------------------------------------ |
| **Share Orchestrations**   | Let a user share owned Orchestrations when unrestricted sharing is off.              |
| **Publish Orchestrations** | Let a user publish owned Orchestrations to the organization.                         |
| **Publisher**              | Grant 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](/admin/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.

| Control                                      | What it does                                                                                                                                               |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Require users to enroll a passkey**        | Requires users in the role to set up a passkey before using Sofie normally.                                                                                |
| **Require passkey after magic-link sign-in** | Requires 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 logout**                         | Signs 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.

<Note>
  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.
</Note>

<Warning>
  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.
</Warning>

## 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.

<Warning>
  Do not grant privileged access just to solve a temporary content-access issue. Use Workspace membership, sharing, or a narrower role when possible.
</Warning>

## Roles versus Workspace membership

Roles control product capabilities. Workspace membership controls access to a specific Workspace.

Example:

| Need                                  | Use                             |
| ------------------------------------- | ------------------------------- |
| User can create Workspaces            | Role permission.                |
| User can access one project Workspace | Workspace membership.           |
| User can manage all users             | Admin role permission.          |
| User can review one CoDraft           | Share 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](/admin/security-center) and [Users, groups, and roles](/admin/users-groups-roles) as part of access review.