> ## 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.

# Types

> Categorize tickets with five ITSM-aligned types including service request, incident, problem, change, and major incident for consistent handling.

Types help categorize tickets based on the kind of request or issue they represent. Use five type options to align with ITSM workflows and ensure consistent handling across different request categories.

<View title="Human" icon="user">
  ***

  ## Type options

  Ravenna provides five type options to categorize tickets:

  <AccordionGroup>
    <Accordion title="Service" defaultOpen>
      Standard service requests for routine support needs. This is the default type for all tickets unless configured differently.

      **Examples:**

      * Software access requests
      * Hardware provisioning
      * General support inquiries
      * Feature requests
    </Accordion>

    <Accordion title="Incident">
      Unplanned interruptions or reductions in service quality that require immediate attention to restore normal operations.

      **Examples:**

      * System outages
      * Application errors
      * Service degradation
      * Access issues blocking work
    </Accordion>

    <Accordion title="Problem">
      Root cause investigations for recurring incidents or systemic issues requiring analysis and long-term resolution.

      **Examples:**

      * Recurring system failures
      * Performance bottlenecks
      * Architecture deficiencies
      * Known error documentation
    </Accordion>

    <Accordion title="Change">
      Planned modifications to systems, infrastructure, or processes that require approval and coordination.

      **Examples:**

      * Configuration updates
      * System upgrades
      * Infrastructure changes
      * Policy modifications
    </Accordion>

    <Accordion title="Access">
      Requests for granting, modifying, or revoking access to systems, applications, or resources.

      **Examples:**

      * Application access provisioning
      * Permission changes
      * Account deactivation
      * Security group modifications
    </Accordion>
  </AccordionGroup>

  ***

  ## Set types

  Types can be assigned in several ways:

  <AccordionGroup>
    <Accordion title="During ticket creation" icon="plus" defaultOpen>
      When creating a ticket, select the type from the form field. The default type is Service unless configured differently on the <Tooltip headline="Forms" tip="Structured intake forms with custom fields" cta="Learn about forms" href="/documentation/tickets/forms/overview">form</Tooltip>.
    </Accordion>

    <Accordion title="Manual updates" icon="pencil">
      Team members with appropriate permissions can update ticket type at any time by clicking the type field in ticket attributes and selecting a new value.
    </Accordion>

    <Accordion title="Bulk operations" icon="layers">
      Select multiple tickets from the ticket list and use bulk actions to update their types simultaneously.
    </Accordion>

    <Accordion title="Workflow automation" icon="workflow">
      Configure <Tooltip headline="Workflows" tip="Automated actions triggered by ticket events" cta="Learn about workflows" href="/documentation/automate/workflows/overview">workflows</Tooltip> to automatically set or change types based on ticket content, conditions, or events.
    </Accordion>

    <Accordion title="AI agent rules" icon="bot">
      Set up <Tooltip headline="AI agent rules" tip="Conditional logic and automation for AI agents" cta="Learn about agent rules" href="/documentation/automate/ai-agents/configure-agents">agent rules</Tooltip> to automatically assign types based on ticket content analysis.
    </Accordion>
  </AccordionGroup>

  <Info>
    Type is a required field. All tickets must have a type assigned. The default type is Service unless customized in form settings.
  </Info>

  ***

  ## Configure default types

  Each <Tooltip headline="Forms" tip="Structured intake forms with custom fields" cta="Learn about forms" href="/documentation/tickets/forms/overview">form</Tooltip> can have its own default type to ensure consistent categorization across similar ticket types.

  <Steps>
    <Step title="Navigate to forms">
      Go to **Settings > Forms** to configure default types.
    </Step>

    <Step title="Select form">
      Choose the specific form you want to configure.
    </Step>

    <Step title="Open settings">
      Click **Settings** for the selected form.
    </Step>

    <Step title="Access defaults">
      Navigate to the **Defaults** section within the form settings.
    </Step>

    <Step title="Set default type">
      Choose the appropriate default type for tickets created with this form.
    </Step>

    <Step title="Save changes">
      Click **Save** to apply the new default type setting.
    </Step>
  </Steps>

  **Example:** Set "Incident Report" forms to default to Incident type, while "Software Access" forms default to Access type.

  ***

  ## Use types

  ### Filter and sort

  Use types to organize your ticket list:

  **Filtering**

  * Filter <Tooltip headline="Views" tip="Saved filters and column configurations for organizing tickets" cta="Learn about views" href="/documentation/tickets/organize/views">views</Tooltip> to show only specific types
  * Create saved filters for quick access to incident or access request tickets
  * Use type filters in dashboards and reports

  **Sorting and grouping**

  * Sort tickets by type
  * Group tickets by type in list views and Kanban boards
  * Organize Kanban boards with type-based columns

  Type is displayed with icons and text labels for easy identification.

  ### Workflows

  Use types in <Tooltip headline="Workflow" tip="Automated actions triggered by ticket events" cta="Learn about workflows" href="/documentation/automate/workflows/overview">workflow</Tooltip> conditions and actions:

  **Triggers**

  * Trigger workflows when tickets are assigned specific types
  * Create specialized workflows for incident or change tickets
  * Set up notifications for access request creation

  **Actions**

  * Automatically set types based on ticket content
  * Change types when conditions are met (such as escalating a service request to an incident)
  * Route tickets to different teams based on type

  **Conditional logic**

  * Use type as a condition in workflow rules
  * Create different approval processes for change requests
  * Route tickets based on type and other criteria

  <Callout icon="link" color="#6B7280">
    Learn more about [building workflows](/documentation/automate/workflows/publish) with type conditions
  </Callout>

  ### Analytics

  Use types in your <Tooltip headline="Analytics" tip="Reports and metrics for tracking ticket performance" cta="Learn about analytics" href="/documentation/measure/analytics">analytics</Tooltip> and reporting:

  * Track ticket volume by type
  * Monitor resolution times across different types
  * Analyze team performance on incidents versus service requests
  * Identify type trends over time
  * Review type changes in ticket event history and activity logs
</View>

<View title="Agent" icon="bot">
  ## Mental model

  Type is a built-in ticket property with a fixed set of five values: service, incident, problem, change, access. Every ticket has exactly one type. The default is service unless a form specifies a different default.

  Type is distinct from categories and tags:

  * **Type** is a single fixed-enum property representing the kind of request (service, incident, problem, change, access).
  * **Categories** are AI-assigned topic labels (one per ticket).
  * **Tags** are freeform multi-labels for supplementary metadata.

  Type helps align Ravenna tickets with ITSM workflows and enables reporting, automation, and routing based on the nature of the request.

  ***

  ## Type assignment patterns

  | Method            | When to use                                                                                                                                                                           |
  | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
  | **Form defaults** | Set per-form defaults so tickets from specific forms start with the right type (for example, "Incident Report" defaults to incident, "Software Access" defaults to access)            |
  | **Agent rules**   | Have the agent assess the request from conversation context and set type accordingly                                                                                                  |
  | **Workflows**     | Auto-set type based on ticket properties (for example, set to incident when specific keywords are detected, change type from service to problem when recurring pattern is identified) |
  | **Manual**        | User or agent sets type during or after ticket creation                                                                                                                               |

  For most workspaces, form defaults handle the majority of cases. Agent rules and workflows handle the exceptions and reclassification.

  ***

  ## Using type in automation

  **Agent rules:** The agent can set type based on conversation analysis. Common patterns:

  * "If the user reports a system outage affecting multiple people, set type to incident."
  * "For access requests to applications, set type to access."
  * "If the user mentions a recurring issue, set type to problem."

  **Workflow triggers:** Type changes can trigger workflows. The "Ticket Updated" trigger with a type filter lets you build specialized automations for different request types.

  **Workflow conditions:** Use type as a branching condition in workflows. For example, if type is incident, notify the on-call team and set priority to high. If type is access, route to the IAM team and require approval.

  **Type-based routing:** Combine type with channel or assignment rules to automatically route tickets to specialized teams (incidents to operations, access requests to security, changes to change management).

  ***

  ## Constraints and gotchas

  * Type values are fixed (service, incident, problem, change, access). You cannot add, remove, or rename type options.
  * Type is a required field. Every ticket has a type, defaulting to service if not specified.
  * The system-wide default type is service. This can be overridden per form but not globally.
  * Type does not sync bidirectionally with external integrations. If a ticket is replicated to Jira, the type in Ravenna and the type in Jira are independent unless a workflow explicitly maps them.
  * Changing a ticket's type does not retroactively affect workflows or automations that already executed. It only affects future workflow evaluations.
</View>