Ordered Triage rules
Classify, route, enrich, and automatically accept Team intake with deterministic rules
Currently unavailable: Ordered Triage automation is disabled while the product workflow is deferred. Core Triage intake, responsibility, snooze/wake, and manual disposition remain available. The details below describe the retained implementation for future re-enablement.
How ordering works
Enabled rules run from top to bottom. A rule can match all or any of its conditions. Label additions and removals accumulate in order. When several matching rules set the same scalar property—such as priority, assignee, Project, destination Team, or automatic acceptance—the later action wins, and the preview identifies that conflict.
Rules can match source, creator, origin Team, title/description text, priority, labels, assignee, and Project. The source is Workspace member, Team Triage, API integration, Cross-Team rule, or Agent. A rule with the source condition Agent matches agent submissions and nothing else. They can route to another Team, set priority, add or remove labels, set an assignee or Project, and accept the Issue automatically. The server rejects unknown fields, operators, versions, and inaccessible or invalid option identifiers.
Route between Teams
A destination Team action ends the source Team's rule pass. The normal Team move contract translates the Issue key, status, labels, hierarchy, and assignee access, then the destination Team's enabled rules run. A route cannot visit the same Team twice and cannot exceed five Team hops. A routed Issue's source becomes Cross-Team rule, whatever it was before, so the destination Team's Agent filter and Agent rules do not match a routed agent submission.
The complete attempted chain is atomic. If a target is unavailable, a route loops, the hop limit is reached, or a property cannot be applied, none of that attempt's Issue changes remain. The Issue stays in Triage with readable failure evidence.
Review evidence and retry
Issue detail shows the latest Triage evaluation without exposing raw rule JSON or private Team names. Authorized editors can retry a failed evaluation after the configuration is corrected. Each retry uses an idempotency key, and later rule edits do not replay unrelated historical intake.
Archiving removes a rule from future evaluation while retaining its versioned configuration and prior Issue evaluation evidence. Team Audit Log records rule create, edit, reorder, enable, and archive changes.