Ticket Workflows

Ticket Workflows let you enforce a staged, repeatable process on a category of tickets. A workflow defines the stages a ticket can be in, the transitions allowed between them, and optional conditions — such as requiring a manager's approval or at least one logged time entry before a ticket can move forward. This is ideal for processes like change management, where work must follow controlled steps rather than jumping freely between statuses.

Workflows are opt-in. A workflow only affects tickets in the category you assign it to. Every other ticket continues to move freely between statuses exactly as before.

Concepts

Term	Meaning
Stage	A step in the process, mapped onto one of your ticket statuses.
Starting stage	The stage(s) a ticket may enter the workflow at. At least one is required.
Transition	An allowed move from one stage to another. If there is no transition between two stages, that status change is blocked.
Approval gate	A transition that requires approval from a chosen role before the status can change.
Time-entry condition	A transition that requires at least one logged time entry on the ticket before it can proceed.

A workflow governs every ticket in its assigned category. Each category can have at most one workflow.

Navigate to Ticket Workflows

Ticket Workflows must be included in your plan. If your organization is not licensed for it, the Ticket Workflows settings page and its navigation entry do not appear, and opening the page directly shows an upgrade prompt instead. Contact your account owner about upgrading if you do not see it.

Go to Administration → Ticket Workflows (/settings/ticket-workflows). The nav item appears for users with the ticket_workflows.read permission (Owners, Admins, the built-in Help Desk Manager role, and Read Only users) on a plan that includes the feature. Creating, editing, and deleting workflows additionally require the matching ticket_workflows create / update / delete permissions.

Create a workflow

1. Click New Workflow.
2. Enter a Name (for example, Change Management) and an optional Description.
3. Choose the category under Applies to category. Tickets in that category will be governed by this workflow. Choose No category (unassigned) to save a definition that governs nothing yet.
4. Leave Enabled on to activate the workflow immediately, or switch it off to save a draft. A disabled workflow governs nothing.
5. Under Stages, check each ticket status that should be a stage, and mark at least one as a Starting stage (the flag icon). A workflow must have at least one stage and at least one starting stage.
6. Under Allowed transitions, click Add transition and pick a from stage and a to stage for each move you want to permit. For each transition you can optionally enable:
   • Requires approval — and pick the approver role (Owner, Admin, or Member) authorized to approve it.
   • Requires time entry — the ticket must have at least one logged time entry before this move is allowed.
7. Click Create workflow.

To change a workflow later, click the edit (pencil) icon. To remove it, click the trash icon and confirm — its category becomes unconstrained again.

note

Each ticket status can be used as a stage once per workflow, a transition cannot start and end on the same stage, and you cannot define the same transition twice. The builder will report these if you try to save an invalid workflow.

How a workflow affects tickets

Once a workflow governs a category, open any ticket in that category and look at the Status panel:

• The status picker is constrained. It only offers the current status plus the stages you can move to next. Statuses that aren't a valid next step are hidden.
• Approval-gated steps are labelled. A transition that needs approval shows "(needs approval)" next to the status.
• The governing workflow is shown. A note reads Governed by the <workflow> workflow · stage: <stage>.

If a ticket entered the category before the workflow existed (so it isn't on a stage yet), it can only move into a starting stage first.

Requesting and granting approval

When someone selects a status that requires approval, the ticket does not change status. Instead, an approval request is opened and an Approval pending banner appears on the ticket, showing the requested status, the role that must approve it, and any reason. While a request is pending, the status picker is locked.

A user who holds the required role (or a higher one in the Owner → Admin → Member hierarchy) sees Approve and Reject buttons on the banner:

• Approve applies the requested status change to the ticket and closes the request.
• Reject leaves the ticket on its current status and closes the request.

Requesting and acting on approvals requires the ticket_workflow_approvals permissions; the Approve/Reject buttons additionally require the update permission. A ticket can only have one pending approval request at a time.

Blocked changes

If a status change isn't allowed by the workflow — it isn't a defined transition, or a condition such as "requires time entry" isn't met — the change is blocked and the reason is shown beneath the status picker (for example, This step requires at least one time entry on the ticket before it can proceed.).

tip

Clearing a ticket's status entirely ("No Status") is always permitted, so a workflow can never leave a ticket stuck with no way out.

Best Practices

• Start small. Map only the statuses that matter to the process as stages; you don't have to include every status.
• Define every legitimate move. A ticket can only follow transitions you create, so make sure normal forward and backward steps (for example, re-opening) are defined.
• Use approval gates sparingly. Reserve them for genuinely controlled steps (such as moving to "Approved for Production") so technicians aren't blocked on routine work.
• Pair "requires time entry" with closing stages. Requiring a time entry before a ticket can close helps ensure work is captured for billing.
• Disable instead of delete while iterating, so you keep the definition without governing tickets.