Workflow automations

Workflow automations connect ticket lifecycle events to actions. They are the main way tickets automatically launch agents, run multi-step task templates, or change status without manual edits.

Triggers

Common triggers include:

• Ticket enters a status
• Comment added (optionally filtered by agent @mention)
• Agent run started and Agent mentioned (from status↔agent bindings)
• Agent run outcome reported via MCP
• Ticket created or fields changed

Matching rules enqueue side effects in order without duplicate agent launches for the same automation.

Actions

Duplicate executing runs for the same ticket and automation are prevented.

Status ↔ Agent bindings

The workflow editor includes a Status ↔ Agent bindings section — a managed layer above raw automations:

• One row = one workflow status + one agent
• At most one agent per status; one agent may bind to multiple statuses
• Saving bindings materializes hidden automations: Enter status → run agent, Comment in status → run agent, and Trigger agent handling
• These managed automations are hidden from the automation editor and cannot be edited or deleted directly
• Configuration proposals must not include managed binding automations in automations; omit the section or send only user-managed automations, and change bindings via statusAgentBindings. Proposal review and History restore handle managed rows accordingly.
• Agent mentioned bindings support preventDefault to suppress the built-in @mention launch when a binding handles the mention differently (for example, running a task template instead)
• When an agent is bound to multiple statuses and triggered from elsewhere, the ticket moves to the bound status with the lowest sort order among candidates

For queued pipelines, use a Run task automation with a template that acquires/releases a queue group instead of binding-only launches.

Conditions

Automation triggers can filter on status, agent, author kind, and structured condition JSON. For branching logic inside multi-step pipelines, use Condition, Switch, and Loop blocks in task templates — not only automation rule filters.

Setup & configuration

Project admins edit automations on each workflow at Settings → Workflows → [workflow] → Automations. Global workflows are edited by superadmins under Platform → Workflows.

Suggested flow:

1. Define the statuses agents should react to (for example "Ready for agent").
2. Add a Run agent action with the right agent and optional status transitions, or use Status ↔ Agent bindings for managed enter-status and mention behavior.
3. For multi-step pipelines, create a task template and wire a Run task automation.
4. Prefer outcome-driven status moves (MCP report_agent_outcome + outcome triggers) over automatic "move on success" when agents report their own results.
5. Test on a non-production ticket before enabling on high-volume workflows.

For recurring automation outside ticket events, see Scheduled tasks.

Related

• Workflows
• Task templates & runs
• Agents overview
• Inbound webhooks — external events that can resolve tickets and run nested actions