> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reelevant.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Permissions
> Understand how the permission system controls access to platform resources
## How Permissions Work
The Reelevant platform uses a **role-based access control** (RBAC) system. Every user is assigned exactly one [role](/product-guide/account/roles) that defines what they can do and which resources they can interact with. Resources are further scoped by [teams](/product-guide/account/teams) so that users only see what belongs to their teams.
The permission evaluation follows three layers:
1. **Role** — Defines which actions the user can perform on which resource types.
2. **Company** — Every permission rule is automatically scoped to the user's company, ensuring complete tenant isolation.
3. **Team** — For team-scoped resources, the user can only access resources that belong to one of their teams.
Every user automatically has permission to read and update their own profile, regardless of their role configuration. These built-in rules cannot be removed.
## Resources
Resources represent the different entities you can manage on the platform. Each resource supports a specific set of [actions](#actions).
| Resource | Description | Scoping |
| --------------------- | ----------------------------------------------------------------------------- | -------------- |
| **Workflow** | [Workflow](/product-guide/workflows/overview) creation and management. | Company + Team |
| **Workflow Settings** | Global workflow configuration (variable profiles, etc.). | Company |
| **Content** | [Content template](/product-guide/contents/overview) creation and management. | Company + Team |
| **Datasource** | [Datasource](/product-guide/datahub/overview) creation and management. | Company + Team |
| **Statistics** | [Analytics](/product-guide/analytics/overview) data access and export. | Company |
| **User** | User account management (invite, edit, delete). | Company |
| **Role** | Role creation and management. | Company |
| **Teams** | Team creation and management. | Company |
| **Company** | Company-level settings and configuration. | Company |
| **Billing** | Billing and subscription access. | Company |
| **Invitation** | User invitation management. | Company |
| **Datagraph Schema** | Datagraph schema definition and management. | Company + Team |
| **Datagraph Entity** | Datagraph entity data access and management. | Company + Team |
### Resource Scoping
Resources fall into two categories based on how access is controlled:
These resources are shared across the entire company. Any user with the appropriate role permission can access them, regardless of which team they belong to.
**Company-scoped resources:** User, Role, Teams, Company, Billing, Invitation, Workflow Settings, Statistics.
These resources belong to one or more teams. A user can only access a team-scoped resource if they are a member of (or inherit access to) one of the resource's teams.
**Team-scoped resources:** Workflow, Content, Datasource, Datagraph Schema, Datagraph Entity.
For example, if a workflow is assigned to the "Marketing" team, only users who are members of "Marketing" (or one of its ancestor teams) can interact with that workflow — provided their role grants the required action.
## Actions
Actions define what operations a user can perform on a given resource. Not every action is available for every resource — the [permissions matrix](#permissions-matrix) shows the full mapping.
| Action | Description |
| ---------- | ---------------------------------------------------------- |
| **Access** | Permission to view the resource section in the navigation. |
| **Create** | Permission to create new instances of the resource. |
| **Read** | Permission to view resource details. |
| **Query** | Permission to search and list resources. |
| **Update** | Permission to modify existing resources. |
| **Delete** | Permission to remove resources. |
| **Export** | Permission to export resource data. |
## Permissions Matrix
The table below shows which actions are available for each resource. When configuring a [role](/product-guide/account/roles), you can toggle each available action individually.
| Resource | Access | Create | Read | Query | Update | Delete | Export |
| --------------------- | :----: | :----: | :--: | :---: | :----: | :----: | :----: |
| **Datasource** | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | |
| **Workflow** | | ✓ | ✓ | | ✓ | ✓ | |
| **Content** | | ✓ | ✓ | | ✓ | ✓ | |
| **Workflow Settings** | | ✓ | ✓ | | ✓ | ✓ | |
| **Statistics** | ✓ | | | | | | ✓ |
| **User** | | ✓ | ✓ | | ✓ | ✓ | |
| **Role** | | ✓ | ✓ | | ✓ | ✓ | |
| **Teams** | | ✓ | ✓ | | ✓ | ✓ | |
| **Company** | | | ✓ | | ✓ | | |
| **Billing** | ✓ | | | | | | |
| **Invitation** | | ✓ | ✓ | | | ✓ | |
| **Datagraph Schema** | ✓ | ✓ | ✓ | | ✓ | ✓ | |
| **Datagraph Entity** | ✓ | ✓ | ✓ | | ✓ | ✓ | |
The **Access** action controls whether the section appears in the platform navigation. For example, granting **Statistics → Access** makes the Analytics section visible to the user.
## Permission Evaluation
When a user tries to perform an action, the system checks the following conditions in order:
Does the user's role include a rule granting the requested action on the target resource type?
Does the target resource belong to the same company as the user? This check is automatic and ensures complete tenant isolation.
Is the user a member of at least one team that the target resource belongs to? Team membership includes inherited access from the [team hierarchy](/product-guide/account/teams#team-hierarchy).
If any check fails, the action is denied with a **403 Forbidden** error.
## Synced Resources
Some resources are automatically linked so their permissions stay in sync:
| When you grant a permission on… | The same permission is also granted on… |
| ------------------------------- | --------------------------------------- |
| **Content** | Content Font Resources |
| **Datasource** | OAuth Clients |
These synced resources are not shown in the role editor — they are managed automatically.
## Built-in Rules
Every role includes two rules that cannot be removed:
| Rule | Effect |
| ---------------------- | ------------------------------------------------------------------------- |
| **Read own profile** | Every user can view their own user profile. |
| **Update own profile** | Every user can edit their own profile (name, password, 2FA, preferences). |
These rules are scoped to the individual user and do not grant access to other users' profiles.
## Common Configurations
An admin role typically grants all actions on all resources. This gives full control over the platform, including user management, billing, and company settings.
An editor role typically grants create, read, update, and delete on **Workflow**, **Content**, and **Datasource** — plus read access to **Statistics**. This lets the user build and manage campaigns without access to account administration.
A viewer role typically grants only read and access actions. Users can browse workflows, contents, and analytics dashboards but cannot make changes.