> ## Documentation Index
> Fetch the complete documentation index at: https://openlayer.com/docs/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](/docs/security/saml-sso#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 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

<AccordionGroup>
  <Accordion title="Are permissions enforced at the project level too?">
    Yes. Permissions are enforced at both the workspace and project levels.
    [Access groups](/docs/security/access-groups) can provide additional
    project-level control.
  </Accordion>

  <Accordion title="Can a project owner bypass their workspace role?">
    Yes. Project owners have full permissions for their projects, regardless of
    their workspace role.
  </Accordion>

  <Accordion title="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.
  </Accordion>
</AccordionGroup>


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