Workflow Order Design

⚙️ Workflows that run in order, and child tickets - design

Discussion #304, asked by @Shadowtech87 · Status: design - to be built after 5.4.0 (Ed, 16 Nov 2026) · How workflows run today: Workflows, Workflow engine - Developer Guide

The ask

1. An order. Several workflows on Ticket created, each matching a category and assigning a team, then a catch-all at the end that assigns everything else - which needs them to run in a known order and the catch-all to know whether an earlier one already acted.
2. Chaining several steps.
3. A child ticket created by a workflow, which can read the parent's custom fields into its description - from a ticket, and from a form.

How it works today (checked in the code, 16 Nov 2026)

Question	Today
In what order do matching workflows run?	No guaranteed order. WorkflowEngine::dispatch() loads every active workflow for the event with no ORDER BY, and runs them all. There is no order column and no "stop".
Does a later workflow see what an earlier one did?	No. Every workflow is handed the same snapshot of the ticket, taken when the event fired. If the first assigns a team, the second still sees no team.
Does every matching workflow run?	Yes, each one whose conditions pass.
Can a catch-all be written today?	Yes, for this example, without any order: give it the condition Category is empty. The category workflows never change the category, so the catch-all only matches what none of them would. It cannot be written as "team is empty", because of the snapshot.
Chaining steps	Already there, within one workflow: its actions run top to bottom, and each can use what the one before produced ({{last.ticket_id}}, {{steps.2.ticket_number}}). A failed action stops that workflow.
A workflow creating a ticket	Create a ticket exists - but the new ticket is not linked to the one that triggered it, and it does not itself run the Ticket created workflows.
The parent's custom fields in the new ticket's text	Not yet: {{ticket.full...}} does not include custom fields.
A form's answers	Yes: {{submission.fields.<question label>}} on Form submitted - but they cannot be used as a condition yet.
Default routing outside workflows	None for teams: ticket type rules (first match wins, in an order you set) decide a new ticket's type; teams are routed by workflows.

Proposed

Each is separate, so they can ship one at a time. Nothing here changes a workflow that exists today - the defaults reproduce today's behaviour.

1. An order you set. Drag workflows into order in the list (per trigger), as ticket type rules already are. Stored as workflows.run_order; dispatch() runs them ORDER BY run_order, id. Existing workflows keep their current (creation) order.
2. "Stop here when this one runs" - a tick per workflow. When a workflow with it ticked matches and runs, the workflows after it for that event are skipped (and say so in their run log). This is the catch-all pattern, done directly: the category workflows tick it; the catch-all, last, catches the rest.
3. Later workflows see earlier changes. Between workflows, the ticket is read again, so a later condition sees the team an earlier one assigned. Open question: on by default, or a setting? Today's behaviour is the snapshot, and an install could rely on it, so the safe default is a setting (Each workflow sees the ticket as the one before left it), off for existing installs and on for new ones.
4. Create a ticket - as a child. An option on Create a ticket: Link it as a child of this ticket (the same parent/child link the ticket screen makes). Optionally, Run the Ticket created workflows for it - off by default, because it could start a chain; the engine's loop protection (chain depth 10, 100 runs per request) still applies.
5. The parent's custom fields in merge codes. {{ticket.custom.<field name>}} (and in {{ticket.full}}), so a child's description can say "New starter: {{ticket.custom.Start date}}".
6. A form's answers as conditions. Form submitted conditions gain each answer, so a workflow can act only when Department is Finance, say.

Decided

Date	Decision
16 Nov 2026	Design now and reply; build after 5.4.0 (Ed).
16 Nov 2026	A workflow's several Create a ticket steps on one form submission each raise their own ticket - fixed in 5.4.0 (the shipped New starter onboarding fan-out raised only the first).

---

See also: Workflows · Workflow category routing - Developer Guide