Understand roles and permissions

A paid plan makes a feature eligible. Your role, project membership, assignment, and the object’s current state determine whether you can perform a particular action.

The access layers

Layer	What it answers
Owning account or organization plan	Is the feature included, and what are its limits?
Project membership	Can this person enter this project?
Role and project overrides	Which actions may this member perform?
Stage assignment	Who does the work and who approves it?
Client link	What may this external visitor see and do?

A person can be a team contact without being an active project member. A project member can be an assignee without managing the whole team.

Review a member’s access

Open the project and choose Team Members → Manage. Select the member and inspect their role/group and any project-specific permission overrides. Give access for the work they need to do, then verify the affected stage.

Use Assignees for execution and Approvers for review decisions. Changing a role in the general team catalog and changing an override on one project are different scopes; inspect the applicable setting before saving.

External clients

Portal visitors use their link permissions rather than a project team role. Viewing, commenting, approval, revision requests, upload, and download are separate capabilities. A visitor doesn’t gain the internal workspace just by reviewing a draft.

Why a control is disabled

Check whether the person belongs to the project, whether their role permits the action, whether the stage is locked or approved, and whether the owning workspace includes the feature. Account read-only/frozen state can also prevent changes.

Ask an owner or authorized manager to change access. Don’t share someone else’s session or integration token to work around a missing permission.

See team management and client access for the specific setup paths.