> For the complete documentation index, see [llms.txt](https://docs.supria.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.supria.com/home/get-started/core-concepts/profiles-and-permissions.md).

# Profiles and permissions

The functions available at each level and what they allow you to access.

Supria Workspaces controls access through roles assigned at different levels: workspace, megaproject, area, and vendor.

There's no single, global list of roles that applies to every context. Instead, permissions are scoped to the level where they're assigned, and some modules define additional roles for their own features. Keep this in mind when auditing or granting access: check the level you're working at, not just a general "roles" list.

***

### User permissions in Supria Workspaces

Access in Supria Workspaces is based on roles and scopes: what a user can do depends on the role assigned to them and where that role was assigned. The same person can be an Owner on one project and a Viewer on another; permissions don't follow the user everywhere, they follow the assignment.

This page summarizes the roles available at each level of the platform.

#### **Workspace level**

Workspace roles define a user's default reach across your entire portfolio.

<table><thead><tr><th width="250">Role</th><th>What they can do</th></tr></thead><tbody><tr><td><strong>Administrator</strong></td><td>Full control over the workspace, including its configuration, and complete rights (create, edit, delete, manage) regarding all projects, programs, and areas contained within it. It is the only role that can grant approval for any pending approval request.</td></tr><tr><td><strong>Portfolio Manager</strong></td><td>The same scope as the Administrator regarding projects, programs, and areas, without workspace configuration rights or unrestricted approval authority.</td></tr><tr><td><strong>Portfolio Viewer</strong></td><td>Read-only visibility across the entire portfolio.</td></tr><tr><td><strong>Project Manager</strong></td><td>You can create new projects and programs; you gain editing rights for a specific project only when assigned as its <strong>Owner</strong>.</td></tr><tr><td><strong>Workspace Member</strong></td><td>Read-only visibility of the workspace itself.</td></tr></tbody></table>

#### **Project level**

Project roles control what a user can do within a specific project: its details, schedule, and status reports.

<table><thead><tr><th width="256">Role</th><th>What they can do</th></tr></thead><tbody><tr><td><strong>Owner</strong></td><td>Edit, delete, and manage the project; create and manage the schedule.</td></tr><tr><td><strong>Contributor</strong> </td><td>View the project and its schedule.</td></tr><tr><td><strong>Viewer</strong></td><td>Read-only access to the project and the schedule.</td></tr></tbody></table>

#### **Megaproject level**

Programs reuse the workspace-level roles (**Administrator**, **Portfolio Manager**, **Portfolio Viewer**) applied to that specific program, plus two roles focused on risk:

<table><thead><tr><th width="253">Role</th><th>What they can do</th></tr></thead><tbody><tr><td><strong>Risk Administrator</strong></td><td>Create, edit, delete, and manage the risk register and its parameters.</td></tr><tr><td><strong>Risk Viewer</strong></td><td>Read-only visibility of the program, its areas, and its risks.</td></tr></tbody></table>

#### **Area and vendor level**

Areas reuse the same **Owner / Contributor / Viewer** roles as a standalone project, applied at the area level. There's an additional role for external parties:

<table><thead><tr><th width="255">Role</th><th>What they can do</th></tr></thead><tbody><tr><td><strong>Owner / Contributor / Viewer</strong></td><td>Same access standard as the project level, restricted to that area.</td></tr><tr><td><strong>Supplier</strong></td><td>Limited access for external partners: they can view and contribute quantities, progress data, baseline requests, and status reports for the area to which they are assigned, without deletion rights and with no access to risk data.</td></tr></tbody></table>

***

### How it all fits together

Roles are assigned per project, per program, or per area, not once for the entire portfolio, which keeps access aligned with responsibility.

A sponsor might have full portfolio visibility as a Portfolio Viewer, while a contractor sees only the area they're delivering, as a Vendor.&#x20;

This precision is what lets you open the platform to a wide range of stakeholders without losing control over who can change what.

***

### Best practices

* Assign roles at the most restrictive level that meets the access need.
  * For example, grant Area-level access instead of Megaproject-level access when a user only needs to work in a specific area.
* Review module-specific roles separately if a user needs access to a specialized module, such as Action Hub.