> ## 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. 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. *** ## Requester The requester is the person who needs help or submitted the ticket. This is typically the end user requiring assistance. Each ticket has exactly one requester, assigned when the ticket is created. The requester receives updates about status changes and new messages throughout the ticket lifecycle. When the requester changes (manually, through an agent, or through a workflow), Ravenna records the change as an event on the ticket timeline. The event shows who made the change, the previous requester, and the new requester. ### Setting the requester When creating tickets in the Portal, the requester field is available in the ticket creation form. The field automatically defaults to you (the person creating the ticket), but you can change it to create tickets on behalf of others. **How it works:** * The requester field appears in the ticket attributes bar * Defaults to your user account * Click the field to select a different user * Useful for creating tickets on behalf of team members or end users Tickets created through Slack messages, form submissions, email, or the Portal automatically set the requester based on who submitted the request: * **Slack**: The user who sent the message * **Forms**: The user who submitted the form * **Email**: The sender of the email * **[Portal](/documentation/platform/portal)**: The user who submitted the form or started the chat that created the ticket *** ## Author The author is the person who physically created the ticket in Ravenna. This may be the same person as the requester or someone acting on their behalf. Each ticket has one author who cannot be changed once set. The author remains fixed throughout the ticket lifecycle. **Common scenarios:** * **Self-service**: Author and requester are the same person * **Proxy creation**: A support agent creates the ticket on behalf of someone needing help * **Escalation**: A manager creates a ticket for a team member's issue requiring formal tracking The author is who created the ticket record in Ravenna. The requester is who the ticket is for (the person needing help). In self-service scenarios, they're the same person. *** ## Assignees The assignee is the person responsible for working on and resolving the ticket. This role can change throughout the ticket lifecycle as work is transferred between team members. Each ticket can have only one assignee at a time, though tickets can exist without an assignee. The assignee receives updates about ticket changes and new messages. ### Assign tickets Assign tickets directly from several locations: * Ticket detail page * Bulk operations in ticket lists * Slack using commands or shortcuts * "Assign to me" quick action button Configure automatic assignment through: * **Channel auto-assignment**: Assign tickets to specific users automatically * **Round-robin**: Distribute tickets evenly among team members * **Workflow automation**: Assign based on ticket conditions, content, or events Unassigned tickets remain in the channel until manually assigned or picked up by team members. *** ## Working on it (agent owner) When an AI agent is actively working a ticket before it's escalated to a human, the agent is shown as the **Working on it** owner on the ticket. This is separate from the human assignee so internal AI routing never affects human-facing systems like notifications, CSAT attribution, or out-of-office delegation. **Where it appears:** * A read-only **Working on it** chip in the ticket attributes bar, alongside Assignee. The chip is only rendered while an agent owns the ticket. * Timeline events when the agent takes or releases ownership. These events are recorded for auditability but do not trigger assignment notifications. **When it's set:** * Inbound Slack DMs, Slack channel messages, and [Portal](/documentation/platform/portal) conversations routed to a configured agent. * The agent owns the ticket while it's still in the pre-publish, agent-only phase. **When it's cleared:** * Automatically when the ticket is published to a human channel (escalation or any other publish path). The human assignee is set at the same time. See [Handoff to a human](#handoff-to-a-human). * The chip disappears from the ticket once cleared. Tickets created through the Portal, email, Slack message shortcuts, integration webhooks, or workflow actions don't get an agent owner — those paths are human-driven or already published. V3+ ### Handoff to a human When the agent escalates a ticket (for example, by publishing it after gathering context), Ravenna picks the human assignee in this order: 1. The specific user the agent's rule names (e.g., a rule that says "after escalation, assign to @Jane"). 2. The first auto-assignee configured on the channel. 3. Unassigned, picked up manually by a team member. The **Working on it** owner is cleared the moment the ticket publishes, so the human assignee always represents the current human owner. *** ## Followers Followers are users who need to stay informed about ticket progress but aren't directly responsible for resolving it. Multiple users can follow a single ticket. Any number of users can follow a ticket and receive updates about changes and new messages. Followers can be added or removed at any time. Following a ticket doesn't grant additional access permissions. ### Manage followers Add followers through: * Ticket detail page * Workflows based on conditions * @mentions in ticket messages (from Slack or the Admin) * CC recipients on inbound emails (added automatically) When you @mention a user in a ticket message, they're automatically added as a follower. This works for both new messages and edits. **Email CC recipients**: When tickets are created or updated via email, CC recipients are automatically added as followers. This respects your channel's guest user settings and allowlist configuration. The system filters out: * Users already following the ticket * The ticket's requester and assignee * Bot users * The message author Users can remove themselves from following tickets. Workflows can also remove followers when conditions are met. Followers receive DM notifications for ticket updates through Slack. Email preferences can be configured for follower updates. For private tickets, @mentions do not automatically add users as followers. This prevents unintended access to sensitive information. Followers receive notifications when tickets are updated, helping teams stay informed without being directly assigned *** ## Approvers Approvers are users who have authority to approve or decline tickets before work can proceed. Approvals use a rounds-based system where each round has its own set of approvers and policy. Tickets can have one or more approval rounds, each with approvers who can approve or decline. Approvals trigger automated actions through workflow integration, and approvers receive notifications across web and Slack. ### Add approvers Add approvers through: * Ticket sidebar Approvers field (individual users or user groups) * Approvals section on the ticket detail page * Workflow automation based on ticket type or conditions * Approval templates for pre-configured round configurations When you select a user group as an approver, the group is automatically expanded into individual users when saved. Only the individual users are stored as approvers on the round. Learn more about [approvals](/documentation/tickets/approvals/overview) including policies, multi-stage rounds, and admin controls ## 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 reminders 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.