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

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