# Roles and Permissions

> Source: https://docs.lorel.ai/en/getting-started/roles-and-permissions/

This page explains the permission model behind "organization roles" and "project roles" — the foundation of access control in Lorel.ai — along with what each role can do and its constraints.

## Overview

Lorel.ai manages permissions across two layers: "organization" and "project."

- **Organization roles** control organization-wide management, contracts/billing, and project creation/management. They follow an orthogonal model of a "management axis" and a "functional scope axis."
- **Project roles** control settings within a project — Integration, AI Agents, Observability, Rules, and creating/running Runbooks. They follow a clear hierarchical model.

The actions a given user can perform are strictly governed by the combination of their organization role and project role.

## What you can do

| Category | Feature/action | Description | Role required |
|---|---|---|---|
| Organization | View organization members | View the full list of users in the organization | All users |
| Organization | Invite a user to the organization | Issue an invitation to an email address | Organization Owner / Manager |
| Organization | Change a member's organization role | Change an existing user's organization role (Owner and Manager can assign different sets of roles) | Organization Owner / Manager |
| Organization | Remove a member from the organization | Remove a user from the organization | Organization Owner / Manager |
| Organization | Leave the organization | Leave the organization yourself (restrictions apply) | All users |
| Organization | Create a project | Create a project in the organization | Organization Owner / Manager |
| Organization | Delete a project | Delete a project in the organization (restrictions apply) | Organization Owner / Manager |
| Project | View project list | View the list of projects | The project's own members, or organization Owner / Manager |
| Project | View project members | View the list of users in a project | The project's own members, or organization Owner / Manager |
| Project | Request to join a project | Send a join request to a "Requestable" project | Any organization role except Guest |
| Project | Directly invite a user to a project | Directly invite an organization member into a project | Project Administrator |
| Project | View join requests | View the list of pending join requests for a project | Project Administrator |
| Project | Approve join requests | Approve another user's join request, adding them as a member | Project Administrator |
| Project | Change a project member's role | Change an existing project member's role | Project Administrator |
| Project | Remove a project member | Remove a user from a project | Project Administrator |
| Project | Leave a project | Leave a project yourself (restrictions apply. Also, this feature is being rolled out in stages and may not yet be available in your environment) | Project members |
| Project | View project features/resources | View Integration, Runbooks, etc. configured in a project. Viewers can also run "Try the connection" on an Access connection | Project members |
| Project | Use some project features/resources | Change incident/task status (escalation excluded) and comment; run Runbooks (run/retry/skip, etc.; Runbooks that include cloud actions require Editor or higher unless the Runbook allows Worker execution); disable Runbooks and move them back to draft | Project Administrator / Editor / Worker |
| Project | Use all project features/resources | The above, plus creating tasks, editing/deleting incidents/tasks, escalating incidents, managing Integration (Sources and Access), creating/changing/deleting Rules, Runbooks, and other definitions (for a Runbook with a step that references an Access activated through manual approval, adding or changing steps and duplicating the Runbook are Administrator-only; so is activating it, including when the Access is referenced through a sub-Runbook), disabling rules, duplicating Runbooks; approving/rejecting Runbook approval steps | Project Administrator / Editor |

## Organization roles and the permission model

There are five organization roles: Owner, Manager, Billing, Member, and Guest.

Organization roles follow a design where a "management axis" (Owner, Manager) — responsible for organization-wide management — and a "functional scope axis" (Member, Billing, Guest) — representing a specific functional area — are orthogonal. There is no simple higher/lower ordering across all roles.

All organization roles, including Guest, share the following: viewing the organization's user list, viewing projects they belong to, and leaving the organization themselves (restrictions apply).

| Organization role | Axis | Main permissions/scope | Roles it can assign/change |
|---|---|---|---|
| Owner | Management | Edit organization info; invite/change role/remove users; create/view/edit/delete projects (even ones not joined); view/manage contract & billing info | Can assign/change all roles |
| Manager | Management | Edit organization info; invite/change role/remove users; create/view/edit/delete projects (even ones not joined); view the "Billing" page and use the Customer Portal and bank-transfer application (cannot request plan changes, cancel renewal, or view invoices) | Can only assign/change Manager / Member / Guest (cannot assign/change Owner or Billing) |
| Billing | Functional scope | Access to most billing and payment features (requesting a plan change and canceling renewal are Owner-only; Billing can only view plan changes) | Own scope only (cannot assign/change roles) |
| Member | Functional scope | Can send join requests to "Requestable" projects | Own scope only (cannot assign/change roles) |
| Guest | Functional scope | Minimum viewing operations only as an organization user (cannot request to join projects) | None |

## Project roles and the permission model

There are four project roles: Administrator, Editor, Worker, and Viewer. They form a strict hierarchy where a higher role includes every permission of the roles below it (strongest to weakest: Administrator > Editor > Worker > Viewer).

| Project role | Scope of action (includes every lower role's permissions) | Restrictions |
|---|---|---|
| Viewer | View and list every feature/resource | All write operations are disallowed |
| Worker | (In addition to Viewer) Change incident/task status (escalation excluded) and comment; run Runbooks (Runbooks that include cloud actions only if the Runbook allows Worker execution); disable Runbooks and move them back to draft | Cannot change rules/settings; cannot escalate incidents; cannot delete or duplicate Runbooks |
| Editor | (In addition to Worker) Create tasks; edit/delete incidents/tasks; escalate incidents; manage Integration (Sources and Access); create/change/delete/disable detection rules, Runbooks, incident policies, agents, and other definitions (for a Runbook with a step that references an Access activated through manual approval, adding or changing steps and duplicating the Runbook are Administrator-only; so is activating it, including when the Access is referenced through a sub-Runbook); approve/reject Runbook approval steps | Cannot manage project members. No role can create incidents manually (they are created automatically when a trigger rule fires) |
| Administrator | (In addition to Editor) Invite/remove/change the role of project members; view and approve join requests; configure the project's manual-approval settings (allowing manual-approval activation) | Editing/deleting the project itself is reserved for the organization's Owner / Manager |

### Key project-specific permission rules

- **Manual-approval settings**: only the project's Administrator can configure the project's manual-approval settings (allowing manual-approval activation). This permission is determined solely by the project role, independent of the organization role.
- **Scope of project detail and member list visibility**: visible only to "the project's own members" or "a user with the organization's Owner / Manager role."

## Constraints on inviting, changing roles, removing, and leaving

The following strict constraints exist to keep the system operating safely and to prevent an organization or project from being left without an administrator.

### Sole-administrator protection

- If an organization has only one Owner, that Owner cannot be demoted, removed, or leave the organization.
- If a project has only one Administrator, that Administrator cannot be demoted, removed, or leave the project.

### Leaving/removal and cascading expiration

- An organization member cannot "remove" themselves. To leave, use the "leave organization" action instead.
- If the target user is the sole Administrator of any project within the organization, the system rejects any attempt to remove or have them leave the organization.
- When a removal or leave from the organization is completed, that user's membership in every project within that organization is automatically revoked as a cascade (unless doing so would leave any of those projects without an Administrator, in which case that specific cascade is skipped as a second layer of protection).

### Invitation and join-request constraints

- Organization invitations are issued as a dedicated invite link (token) sent to an email address. The same email address cannot receive a duplicate invitation, and the invited email address must exactly match the email address of the logged-in user accepting it.
- Directly inviting a user to a project requires that the user already be a member of that organization.
- If an invitation email arrives for an organization the recipient has already joined, the join screen shows an error and they cannot join again (duplicate-join prevention).
- Join requests can only be made to "Requestable" projects. The system rejects any join request from a user with the Guest organization role.

## Related pages

- [Organizations and Projects Overview](/en/getting-started/organization-project-overview/)