Browse documentation
Building a workflow
A workflow automates what should happen when something occurs — ask for an approval, assign a ticket, raise a task, send a notification — and can branch part-way through depending on what it finds. Workflows are an optional module; enable it under Settings → Modules.
The workflows page
Select Workflows. It has two tabs:
- Workflows — your workflow definitions.
- Runs — each time a workflow has run, with its state (Running, Waiting approval, Completed, Rejected, Cancelled, or Failed).
Choosing a trigger
- Select New workflow.
- Give it a name and optional description.
- Choose a trigger:
| Trigger | Fires when |
|---|---|
| Manual | You start it yourself and supply any context values. |
| When a ticket is created | A helpdesk ticket event occurs — see below. |
| When a change's status changes | A change moves through its lifecycle. |
The trigger matters beyond when the workflow starts: it decides which nodes you can use. Change workflows get a different palette from ticket and manual ones.
Ticket workflows listen for more than creation
Despite the trigger's name, a ticket workflow can listen for any of fifteen lifecycle events, not just creation:
Ticket created · Comment added · Status changed · Priority changed · Assigned · Unassigned · Category changed · Department changed · Resolved · Closed · Reopened · Item linked · Item unlinked · SLA first response breached · SLA resolution breached
Pick the events you want. A workflow built before this existed listens for Ticket created only, so it still runs exactly once.
The canvas
Workflows are built on a drag-and-drop canvas, not as an ordered list of steps. You drop nodes onto it and connect them; the connections decide what runs after what, and a Condition node lets a workflow take different paths.
| Node | What it does | Available on |
|---|---|---|
| Trigger | The entry point — the trigger you chose above. | All |
| Condition | Branches the workflow on a field. Pick the source module first, then a field and a comparison. | All |
| Approval | Pauses the run and asks a person to decide. See Approvals. | Manual, Ticket |
| Require approval | Raises an approval against a Change Advisory Board or named approver. Does not pause the run. See Approvals. | Change |
| Assign | Sets who the ticket is assigned to. | Manual, Ticket |
| AI assist | Reads the source ticket and assists with it — offered only on ticket workflows, since it needs a ticket to read. | Ticket |
| Create task | Raises a task for someone. | All |
| Notify | Sends a message to chosen recipients. | All |
| End | Ends that branch of the workflow. | All |
Configure a node by selecting it and filling in its panel — approver, assignee, recipients, titles, messages, priority, due dates — then save the workflow.
Using context
Nodes can include placeholders that fill in from the workflow's context. A ticket workflow can use values like the ticket number, subject, priority, category, and requestor; a change workflow can use the change's own fields. For a manual workflow, you enter the context values when you start it.
Running a workflow
- Manual workflows have a Start button — you supply any context values, then it runs.
- Ticket and change workflows run on their own when a matching event occurs.
Follow progress on the Runs tab — see Approvals for how approval nodes behave and how to read a run's timeline.
Notes & tips
- Start simple: an Approval → Create task pair covers many "request and action" processes.
- Use Condition to avoid building near-identical workflows — one workflow that branches is easier to maintain than three that nearly match.
- Deactivate a workflow (rather than deleting it) to pause it while keeping its history.