> ## 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. # Statuses > Track ticket progress with flexible status system including system statuses and custom sub-statuses that can be assigned to specific forms Statuses track ticket progress through your workflow. Use five system statuses as categories, then create custom sub-statuses underneath them for granular process management. Assign custom statuses to specific forms to match different workflows. *** ## System statuses Every ticket uses one of five system statuses. These categories organize your workflow and serve as groups for custom sub-statuses. } defaultOpen> New tickets that haven't been started. This is the default status for all newly created tickets. }> Tickets actively being worked on by team members. }> Tickets on hold or waiting for external input, customer response, or other dependencies. }> Tickets that have been completed and resolved but may need final verification. }> Tickets fully completed and archived. System statuses cannot be deleted or modified. They serve as permanent categories for organizing your workflow. *** ## Status hierarchy Ravenna uses a two-level status system: **System statuses** * Five main categories (Open, In Progress, Waiting, Done, Closed) * Available to all tickets regardless of form * Cannot be deleted or modified * Serve as groups for custom sub-statuses **Custom sub-statuses** * Created under system status categories * Must be assigned to specific forms to be usable * Provide granular tracking for specific processes * Each form can have different available sub-statuses This hierarchy lets you create detailed status flows for different ticket types while maintaining consistent top-level categories across your organization. *** ## Create custom statuses Custom sub-statuses provide specific status options beyond the five system statuses. After creating a custom status, assign it to forms to make it available for tickets. Go to **Settings > Statuses** to access status management. Click **Add** to open the create status modal. Enter a label for your custom status and select which system status it belongs under. Click **Save** to create the status. Custom statuses won't be usable until assigned to forms. Continue to the next section to assign them. Status labels must be unique across your workspace. You can't create or rename a sub-status to a label that's already used by another status, even if that status sits under a different system status group. ### Assign statuses to forms Custom statuses must be assigned to specific forms before they appear as options on tickets. Go to **Settings > Forms** to configure form statuses. Select the form you want to configure. Navigate to the **Statuses** section for that form. Select which custom sub-statuses should be available for tickets created with this form. Click **Save** to apply the status configuration. **Example:** Create "Needs Review" and "Testing" sub-statuses under "In Progress", then assign them to your Bug Report form. Feature Request forms can have different sub-statuses like "Planning" and "Awaiting Approval". *** ## Use statuses ### Set status during creation When creating a ticket: * Default status is **Open** * Available statuses include all system statuses plus custom sub-statuses assigned to the selected form * Status can be changed immediately after creation ### Change status Update status from the ticket detail page: Navigate to the ticket you want to update. Click the status field and select the new status from the dropdown. The status change saves automatically and records in ticket history. Update multiple tickets at once: From the ticket list, select multiple tickets using checkboxes. Click the bulk actions menu. Select "Update Status" and select the new status. Confirm to apply the status change to all selected tickets. Send a reply and resolve the ticket in a single action using the **Send and resolve** option in the message composer. Click the dropdown arrow next to the **Send** button in the message composer. Select **Send and resolve** from the menu. This becomes the default action for subsequent messages. Click the button or press **Mod+Enter** to send the message publicly and set the ticket status to **Done**. Configure workflows to automatically update statuses based on ticket events, conditions, or actions. Common patterns: * Auto-progress to "In Progress" when ticket is assigned * Move to "Waiting" when requesting customer information * Change to "Done" when resolution is posted *** ## Organize with statuses Use statuses to organize and filter your ticket list. ### Filter by status Use status filters in views to focus on relevant tickets: * Filter by specific status or status group * Show only tickets with certain statuses * Exclude tickets with specific statuses * Create saved filters for quick access ### Group and sort **List and table views** * Group tickets by status for better organization * Collapse or expand status groups * See ticket counts per status * Sort by status in alphabetical or custom order **Kanban view** * Organize tickets in columns by status * Drag and drop tickets between status columns * Visual process management with status-based workflow *** ## Form-specific configurations Different forms can have different available statuses to match their workflows. **Bug reports** might use: * Open → In Progress → Needs Review → Done → Closed **Feature requests** might use: * Open → Planning → In Progress → Testing → Done → Closed **Support tickets** might use: * Open → In Progress → Waiting → Done → Closed System statuses are always available to all forms. Custom sub-statuses must be explicitly assigned to each form where they should appear. Learn more about [building workflows](/documentation/automate/workflows/publish) with status conditions and actions ## Mental model Status is a two-level system: five fixed system statuses and optional custom sub-statuses underneath them. **System statuses (fixed, always available):** | Status | Meaning | Active/Resolved | | --------------- | --------------------------------------- | --------------- | | **Open** | New, unstarted ticket | Active | | **In Progress** | Actively being worked on | Active | | **Waiting** | Blocked on external input or dependency | Active | | **Done** | Resolved, may need verification | Resolved | | **Closed** | Fully completed and archived | Resolved | Every ticket has exactly one status at any time. The default status for new tickets is Open. **Custom sub-statuses** nest under a system status and provide granular tracking. A sub-status like "Needs Review" under "In Progress" inherits the system status semantics (still active, still in progress) while adding process detail. Sub-statuses are workspace-scoped but form-gated: they must be explicitly assigned to specific forms before tickets using those forms can use them. Different forms can have different sub-statuses available, enabling form-specific workflows within the same workspace. *** ## Custom sub-status design patterns Design sub-statuses around the distinct workflows in your workspace: **Approval-heavy workflows (e.g., access requests):** * Open → Pending Approval (under Waiting) → Approved (under In Progress) → Provisioned (under Done) → Closed **Development workflows (e.g., bug reports):** * Open → Investigating (under In Progress) → Fix in Progress (under In Progress) → Needs Review (under In Progress) → Done → Closed **External dependency workflows (e.g., vendor requests):** * Open → In Progress → Waiting on Vendor (under Waiting) → Vendor Responded (under In Progress) → Done → Closed When designing sub-statuses, keep them scoped to the forms that need them. A "Needs Review" sub-status is relevant for bug reports but not for password reset requests. This prevents status dropdowns from becoming cluttered with irrelevant options. *** ## Status in automation **Workflow triggers:** The "Status Changed" trigger fires when a ticket's status changes. You can filter on specific status transitions (e.g., only fire when status changes to Done). **Workflow actions:** The "Set Status" action changes a ticket's status as part of a workflow. Use it for auto-progression (e.g., set to "In Progress" when assigned, set to "Done" when an approval is completed). **Agent rules:** The agent can set ticket status based on conversation context. Common patterns: * "When you resolve a user's issue, set the ticket status to Done." * "If the user says they need to check with their manager, set status to Waiting." **Status-driven patterns:** * Trigger a CSAT survey when status changes to Done. * Notify the requester when status changes from Waiting to In Progress. * Auto-close tickets that have been in Done status for a configured period. *** ## Constraints and gotchas * The five system statuses (Open, In Progress, Waiting, Done, Closed) cannot be renamed, deleted, or reordered. They are permanent. * Custom sub-status labels must be unique within a workspace. Two sub-statuses cannot share the same label, even if they sit under different system status groups. Ravenna rejects any attempt to create or rename a sub-status to a label that's already in use. * Custom sub-statuses must be assigned to forms before they can be used. Creating a sub-status alone does not make it available on any ticket. * A sub-status inherits the semantics of its parent system status. A sub-status under "Done" is considered resolved regardless of its name. * Tickets can transition between any statuses freely. There are no enforced status transition rules (e.g., you can go from Open directly to Closed). Enforce transitions through workflow logic if needed. * Kanban board columns map to statuses. Each status (system or custom) becomes a column. * Bulk status updates apply the same status to all selected tickets. If tickets span different forms with different available sub-statuses, only commonly available statuses will be selectable. * Status changes are recorded in ticket history with timestamps. This data is available in analytics for tracking resolution times and workflow efficiency.