Permissions

Roles handle the default. Exceptions handle the unusual cases.

How access works

Start with a role. That should solve most access questions on its own.

In Settings > Team, every member has a workspace role plus an Access panel. The role sets the baseline. Access exceptions only exist for the cases where one person needs something different.

Use roles first

Roles are broad on purpose. If someone should usually create products, review assets, or manage the team, give them the role that matches that job instead of stacking overrides on top.

A good rule: if you are about to add three or four exceptions to make a role fit, the role is probably wrong.

When to use exceptions

Exceptions are for unusual cases, not day-to-day team setup.

Common examples:

  • A supplier needs upload access to one product without getting a broader editor role.
  • A freelancer needs temporary access to one folder for a launch project.
  • An editor should be blocked from one sensitive collection without changing the rest of their role.

Two kinds of exceptions

The Access modal separates exceptions into two tabs:

  • Organization-Level changes one permission across the whole workspace.
  • Resource-Level changes one permission for a specific asset, folder, collection, or product.

Temporary access

Every exception can expire. That is the cleanest way to handle agencies, contractors, and short-lived projects.

If you know access should end, set the expiry when you create the exception. That keeps the workspace tidy and avoids permission drift later.

Practical workflow

  1. Pick the role that matches the member's normal job.
  2. Open Access only if the role is almost right but not quite.
  3. Add the smallest exception that solves the problem.
  4. Set an expiry if the exception should not last forever.