> ## Documentation Index
> Fetch the complete documentation index at: https://docs.serval.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom Ticket Types

> Define your own team-specific ticket types with their own lifecycle, transitions, workflows, and fields

Beyond the built-in ticket types — Request, Incident, Major Incident, Change, and Problem — Serval lets each team define its own **custom ticket types**. A custom type bundles its own lifecycle, status transitions, entry workflows, and custom fields, so you can model a process that doesn't fit the standard types.

***

## What Is a Custom Ticket Type?

A **custom ticket type** is a ticket type you author for your team's specific needs — for example, Legal Intake, Onboarding, Access Review, or Facilities Request. Each custom type is fully self-contained:

* Its own **lifecycle** — the statuses a ticket moves through from creation to closure
* Its own **transition rules** — which status can move to which, with optional conditions
* Its own **entry workflows** — automations that run when a ticket enters a status
* Its own **custom fields** — the information captured on tickets of that type

Custom types use the same underlying model as [change models](/sections/documentation/ticketing/change-management), so everything you can configure on a change model — lifecycle, transitions, automations, and fields — is available on a custom type.

<Tip>
  Reach for a custom type when a process needs its own distinct lifecycle and fields. If you only need different statuses or SLAs on an existing type, configure those directly instead — see [Statuses](/sections/documentation/ticketing/ticket-configuration/statuses) and [SLAs](/sections/documentation/ticketing/ticket-configuration/slas).
</Tip>

***

## Creating a Custom Type

Custom types are configured in **Team Settings → Ticket Types**, in the **Custom Types** group of the left sidebar.

<Steps>
  <Step title="Open Ticket Types settings">
    Go to **Team Settings → Ticket Types**. In the sidebar, find the **Custom Types** group.
  </Step>

  <Step title="Create the type">
    Click **Create custom type**. Give it a name (for example, "Legal Intake") and an identifier. The identifier is derived from the name and used to reference the type.
  </Step>

  <Step title="Configure the lifecycle">
    In the editor, define the statuses the type moves through, which status is the starting point, and the order they appear in.
  </Step>

  <Step title="Add transitions and workflows">
    Set which statuses can transition to which, add any conditions that must be met to advance, and attach entry workflows that run when a ticket enters a status.
  </Step>

  <Step title="Add custom fields">
    Configure the custom fields captured on tickets of this type.
  </Step>

  <Step title="Publish">
    A new custom type starts as a **draft**. When it is ready, publish it to make it available for creating tickets.
  </Step>
</Steps>

<Note>
  Creating and editing custom types requires the permission to manage ticket models, so this is typically limited to team managers and administrators.
</Note>

***

## Draft, Published, and Deprecated

Custom types move through a lifecycle of their own, so you can build and retire them without disrupting existing tickets.

| State          | What it means                                                                                                |
| :------------- | :----------------------------------------------------------------------------------------------------------- |
| **Draft**      | The type is being configured. It isn't offered when creating tickets yet.                                    |
| **Published**  | The type is live and available in the Create Ticket dialog.                                                  |
| **Deprecated** | No new tickets can be created with the type, but existing tickets keep it and remain visible and filterable. |

Publish a type when it's ready, and deprecate it when you no longer want new tickets created with it. Deprecating is the safe way to retire a type that already has tickets — nothing is lost.

***

## Configuring a Custom Type

Everything about a custom type is configured in its editor under **Team Settings → Ticket Types**.

### Lifecycle and Statuses

Each custom type has its own set of statuses and a designated starting status. When a ticket of that type is created, it begins at the starting status. You can manage the pool of statuses available to custom types from **Team Settings → Statuses**, under the **Custom** tab.

### Transition Rules

Transitions control how a ticket moves between statuses. Each transition can carry a condition that must be satisfied before the ticket can advance — for example, requiring certain fields to be filled. See [Statuses](/sections/documentation/ticketing/ticket-configuration/statuses) for more on building status flows.

### Entry Workflows

Attach a [workflow](/sections/documentation/workflows/overview) to a status so it runs automatically when a ticket enters that status — for example, to request an approval, send a notification, or run a validation check.

### Custom Fields

Each custom type has its own custom fields, tailored to the information that type of ticket needs to capture. See [Custom Fields](/sections/documentation/ticketing/ticket-configuration/custom-fields).

***

## Working with Custom-Typed Tickets

**Creating a ticket** — Published custom types appear directly in the ticket type selector of the Create Ticket dialog. Selecting one starts the ticket at that type's initial status and shows its custom fields.

**Filtering** — Custom types appear in the ticket filters so you can slice ticket lists and views by type. Deprecated types stay filterable so their existing tickets remain reachable.

**On the ticket** — A custom-typed ticket displays its type name wherever tickets are listed or opened, so it's always clear which type a ticket belongs to.

***

## Deleting vs. Deprecating

* **Delete** a custom type only when no tickets use it. Deleting removes the type along with its lifecycle, transitions, and entry workflows. A draft that was never used can be safely deleted.
* **Deprecate** a type that already has tickets. Deprecating stops new tickets while keeping existing ones intact and filterable.

If you try to delete a type that still has tickets, Serval blocks the deletion and points you to deprecate it instead.

***

## Related Pages

* [Ticket Types](/sections/documentation/ticketing/ticket-configuration/ticket-types)
* [Change Management](/sections/documentation/ticketing/change-management)
* [Statuses](/sections/documentation/ticketing/ticket-configuration/statuses)
* [Custom Fields](/sections/documentation/ticketing/ticket-configuration/custom-fields)
* [Workflows](/sections/documentation/workflows/overview)