How trigger execution order works

There are two things that determine which triggers run and in what order: the kickoff event type and the position of each trigger on the Triggers page.

Only matching triggers run

Each trigger has a kickoff event type, like "New issue created" or "Issue has new message." When an event happens, only triggers with a matching kickoff type are evaluated. All other triggers are skipped entirely.

Matching triggers run top to bottom

Among the triggers that match, execution follows the order they appear on the Triggers page, from top to bottom. This includes the order of groups. All matching triggers in the first group run before any matching triggers in the second group, and so on.

You can drag both groups and individual triggers to change the order.

Later triggers cannot re-trigger earlier ones

Within a single run, if a trigger changes a field that an earlier trigger was filtering on, the earlier trigger will not re-run. Triggers only evaluate once per run, in order.

For example: if "Auto-tag billing issues" is below "Route to billing team" and the action from "Auto-tag billing issue adds a tag that matches the kickoff for "Route to billing team" the routing trigger evaluates before the tag exists and skips. Even though the tag gets added afterward, the routing trigger does not re-run. To fix this, move the tagging trigger above the routing trigger.

Example

Say your Triggers page has two groups in this order:

• Routing - contains "Auto-tag billing issues" (kickoff: New issue created) and "Set SLA policy" (kickoff: New issue created)

• Webhooks - contains "Send webhook on tag change" (kickoff: Issue tag changed)

When a new issue is created, only the two triggers with the "New issue created" kickoff run, top to bottom across groups:

1. Auto-tag billing issues (Routing group)

2. Set SLA policy (Routing group)

"Send webhook on tag change" is skipped because it's kickoff types do not match.