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

# Roles and permissions

> Understand the workspace roles in Openlayer and the permissions each role grants.

Openlayer uses **role-based access control (RBAC)** to manage what members of a workspace can do. Every workspace member is assigned one of four roles, listed below from most to least permissive.

| Role | Description |
| - | - |
| **Admin** | Full control over the workspace, its settings, and content. |
| **Member** | Can create and modify content but **cannot** manage workspace settings or members. |
| **Member Restricted** | Same as Member, but **cannot** view data. |
| **Viewer** | Read-only access. Cannot create, modify, or delete anything. |

There is a fifth role, **No access**, which you cannot assign to a member directly. It exists only as
a target when you map identity provider groups to Openlayer roles, so that a group synced from your
IdP can be recognized without being granted anything. See
[No access](#the-no-access-role).

## When to use each role

* **Admin**: workspace owners and administrators who need full control over settings, members, and integrations.
* **Member**: engineers and data scientists who create and manage projects, tests, and data.
* **Member Restricted**: contractors or external collaborators who need creation capabilities without access to sensitive data.
* **Viewer**: stakeholders, executives, or auditors who need visibility without modification rights.

## The No access role

**No access** is assigned only through [directory sync group mapping](https://docs.openlayer.com/security/saml-sso.md#directory-sync-and-role-mapping).
Map an IdP group to it when the group is pushed to Openlayer but its members should not be able to
use the workspace.

A member on this role keeps a membership record, so they still appear in directory sync and can be
promoted later by moving their group to a real role, but they hold no permissions. In practice:

* The workspace does not appear in their workspace switcher.
* Requests for its data are refused, and the actions they cannot take are hidden from the UI rather
  than failing when clicked.

This is the difference between **No access** and removing someone: removing them ends the
membership, while No access keeps it and grants nothing. Under directory sync, a member who belongs
to no mapped group loses their membership entirely.

## Permission matrix

To browse the live catalog in the app, go to **Settings → Members** and select **View permission
matrix**. That button appears if you can invite members (Admin). The in-app matrix is searchable
and is the current source of truth; the table below is a static reference.

| Permission | Admin | Member | Member Restricted | Viewer |
| - | :-: | :-: | :-: | :-: |
| **View data** | ✓ | ✓ | ✗ | ✓ |
| **Export data** | ✓ | ✓ | ✓ | ✗ |
| **Export framework evidence** | ✓ | ✓ | ✓ | ✗ |
| **Run inference** | ✓ | ✓ | ✓ | ✗ |
| **Create projects** | ✓ | ✓ | ✓ | ✗ |
| **Update projects** | ✓ | ✗ | ✗ | ✗ |
| **Delete projects** | ✓ | ✗ | ✗ | ✗ |
| **Create inference pipelines** | ✓ | ✓ | ✓ | ✗ |
| **Delete inference pipelines** | ✓ | ✗ | ✗ | ✗ |
| **Pause inference pipelines** | ✓ | ✗ | ✗ | ✗ |
| **Create frameworks** | ✓ | ✓ | ✓ | ✗ |
| **Update frameworks** | ✓ | ✗ | ✗ | ✗ |
| **Delete frameworks** | ✓ | ✗ | ✗ | ✗ |
| **Create rules / rule tags** | ✓ | ✓ | ✓ | ✗ |
| **Update rules / rule tags** | ✓ | ✗ | ✗ | ✗ |
| **Delete rules / rule tags** | ✓ | ✗ | ✗ | ✗ |
| **Create project tags** | ✓ | ✓ | ✓ | ✗ |
| **Update project tags** | ✓ | ✗ | ✗ | ✗ |
| **Delete project tags** | ✓ | ✗ | ✗ | ✗ |
| **Create tests** | ✓ | ✓ | ✓ | ✗ |
| **Update tests** | ✓ | ✓ | ✓ | ✗ |
| **Create commits** | ✓ | ✓ | ✓ | ✗ |
| **Create comments** | ✓ | ✓ | ✓ | ✗ |
| **Create / update / delete environment variables** | ✓ | ✗ | ✗ | ✗ |
| **View environment variables** | ✓ | ✓ | ✓ | ✓ |
| **Create / update / delete access groups** | ✓ | ✗ | ✗ | ✗ |
| **View access groups** | ✓ | ✓ | ✓ | ✓ |
| **Invite members** | ✓ | ✗ | ✗ | ✗ |
| **Remove members** | ✓ | ✗ | ✗ | ✗ |
| **Update member roles** | ✓ | ✗ | ✗ | ✗ |
| **Update workspace** | ✓ | ✗ | ✗ | ✗ |
| **Delete workspace** | ✓ | ✗ | ✗ | ✗ |
| **Manage SAML SSO** | ✓ | ✗ | ✗ | ✗ |
| **Connect Slack** | ✓ | ✗ | ✗ | ✗ |
| **View billing** | ✓ | ✗ | ✗ | ✗ |
| **View metric settings** | ✓ | ✓ | ✓ | ✓ |
| **View LLM evaluator** | ✓ | ✓ | ✓ | ✓ |
| **View notification settings** | ✓ | ✗ | ✗ | ✓ |

## FAQ

> [accordion] Are permissions enforced at the project level too?
>
> Yes. Permissions are enforced at both the workspace and project levels.
> [Access groups](https://docs.openlayer.com/security/access-groups.md) can provide additional
> project-level control.

> [accordion] Can a project owner bypass their workspace role?
>
> Yes. Project owners have full permissions for their projects, regardless of
> their workspace role.

> [accordion] Can Member Restricted users still access data indirectly?
>
> Yes. Member Restricted users cannot view data directly, but they can still
> export data, export framework evidence, and run inference, which may expose
> data indirectly. Keep this in mind when assigning this role.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.