*** 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 web 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, or email 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 *** 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 Customer 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 web 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 web app) * 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