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

# Roles

> Understand ticket roles in Ravenna including requester, assignee, followers, and stakeholders, and how each affects access, notifications, and workflow.

Every ticket has specific roles that control access, notifications, and workflow permissions. Understanding these roles helps ensure the right people are involved at the right time.

<Callout icon="link" color="#6B7280">
  Ticket roles are the most granular of three access layers. See [Roles and access](/documentation/platform/roles-access) for how organization roles, workspace access, and ticket roles combine.
</Callout>

## Mental model

Every ticket has a set of roles that determine who can see the ticket, who gets notified, and who can take specific actions. Roles are the fundamental access and notification primitives on a ticket.

There are six distinct roles:

| Role              | Cardinality  | Mutable                         | Purpose                                                                                                                                                                          |
| ----------------- | ------------ | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Requester**     | Exactly one  | Yes (can be changed)            | The person the ticket is for, the person needing help                                                                                                                            |
| **Author**        | Exactly one  | No (fixed at creation)          | The person who created the ticket record in Ravenna                                                                                                                              |
| **Assignee**      | Zero or one  | Yes (can be changed or removed) | The human responsible for resolving the ticket                                                                                                                                   |
| **Working on it** | Zero or one  | Set and cleared automatically   | The AI agent actively working the ticket before human handoff. Read-only; cleared on publish.                                                                                    |
| **Followers**     | Zero or many | Yes (can be added or removed)   | Users who receive notifications but are not responsible for resolution                                                                                                           |
| **Approvers**     | Zero or many | Yes (can be added or removed)   | Users with authority to approve or decline the ticket via [approval rounds](/documentation/tickets/approvals/rounds). User groups are expanded into individual users when saved. |

Key distinction: the requester is who the ticket is **for**. The author is who **created** the ticket. In self-service scenarios these are the same person. In proxy creation (an agent creates a ticket on behalf of someone), they differ.

***

## Role assignment methods

| Role              | Automatic assignment                                                                     | Manual assignment                                                      | Workflow assignment                |
| ----------------- | ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------- |
| **Requester**     | Set to message sender (Slack, email, form)                                               | Can be changed in ticket creation form or ticket details               | Yes, via workflow actions          |
| **Author**        | Always the person who created the ticket                                                 | Cannot be changed                                                      | N/A                                |
| **Assignee**      | Channel auto-assignment, round-robin                                                     | Ticket details, bulk operations, Slack commands                        | Yes, via workflow actions          |
| **Working on it** | Set when an agent picks up an inbound conversation; cleared when the ticket is published | Not manually editable                                                  | N/A (managed by the agent runtime) |
| **Followers**     | @mentions in messages, email CC recipients                                               | Ticket details page                                                    | Yes, via workflow actions          |
| **Approvers**     | N/A                                                                                      | Ticket creation form (individual users or user groups), ticket details | Yes, via workflow actions          |

***

## Roles and notifications

All human roles except author receive notifications:

* **Requester**: Notified of status changes and new public messages.
* **Assignee**: Notified of ticket changes, new messages, and assignment changes.
* **Followers**: Notified of ticket updates via Slack DM. Email preferences are configurable.
* **Approvers**: Receive approval request notifications with action buttons. Automatic <Tooltip headline="Approval reminders" tip="Automatic nudges to pending approvers on a schedule" cta="Learn about approval reminders" href="/documentation/tickets/reminders">reminders</Tooltip> for pending approvals.
* **Working on it**: No notifications. Agent ownership is internal routing and is intentionally excluded from assignment notifications, CSAT attribution, and OOO delegation.

***

## Roles and private ticket access

For private tickets, roles determine visibility:

* Requester, assignee, followers, and approvers all have access while they hold their role.
* Workspace members and admins always have access regardless of ticket roles.
* Removing someone from a role (e.g., removing a follower) revokes their access unless they qualify through another role.
* @mentions in private tickets do NOT automatically add users as followers. You must explicitly add them to a role.

***

## Roles in automation

**Workflows:** Use roles as triggers, conditions, and actions. Common patterns:

* Trigger on assignee change to notify the new assignee's manager.
* Add approvers automatically based on ticket type or form.
* Add followers based on ticket channel or category.

**Agent rules:** The agent can reference roles when determining behavior. For example, the agent can check who the requester is to personalize responses, or add followers when escalating.

**Dynamic values:** Role fields (requester name, assignee email, etc.) are available as dynamic values in workflow actions for notifications, messages, and routing logic.

***

## Constraints and gotchas

* A ticket always has exactly one requester and one author. Author cannot be changed after creation.
* A ticket can have at most one assignee. Assigning a new person replaces the previous assignee.
* Followers added via @mention work in public tickets but not in private tickets. For private tickets, you must explicitly add followers.
* Email CC recipients are added as followers automatically, but the system filters out the requester, assignee, bot users, existing followers, and the message author.
* Assigning a user to a task within a ticket automatically adds them as a follower on the parent ticket.
* Approvers operate within [approval rounds](/documentation/tickets/approvals/rounds). Each round has a policy (ANY, ALL, or THRESHOLD) that determines when the round completes. Rounds run sequentially.
* Removing a follower or approver from a private ticket revokes their access immediately, unless they hold another qualifying role.