Skip to main content

Ticket Automations

TOW Automations run Jira-style ticket flows from ticket events, schedules, manual runs, and incoming webhooks. Project admins manage project flows from Project Settings -> Automations. Organisation admins manage global flows from Automations in the main navigation.

Flow Shape​

Each flow has one trigger and an ordered list of steps.

  • Triggers include ticket created, updated, field value changed, assigned, commented, comment edited, linked, link deleted, transitioned, work logged, Agent run completed, manual, scheduled, multiple events, version events, incoming webhook, and connector-backed development events.
  • Conditions include ticket fields, smart-value comparisons, TQL, related tickets, users, attachments placeholders, and if/else blocks with Jira's two-level nesting limit.
  • Branches can run over parents, subtasks, epic children, linked tickets, recently created tickets, TQL lookup results, and advanced smart-value lists.
  • Actions include transition, edit, assign, comment, create, clone, delete, link, unlink, create subtasks, checklist items, log work, lookup tickets, run an AI Agent, create or release versions, variables, re-fetch, web requests, delays, and connector-gated external actions.

Transition actions use the same workflow enforcement as manual ticket changes. Required fields, project roles, restricted transitions, and ticket.transition permission still apply. Failures are visible in the flow audit log.

Smart Values​

Supported smart values include:

  • {{issue.*}}
  • {{triggerIssue.*}}
  • {{branchIssue.*}}
  • {{fieldChange.*}}
  • {{comment.*}}
  • {{webhookData.*}}
  • {{lookupIssues}}
  • {{createdIssue}}
  • {{agentRun.*}}
  • {{agentTrigger.*}}
  • {{now}}

Lookup lists can be rendered with:

{{#lookupIssues}}
{{key}} - {{summary}}
{{/}}

Compose automations and Agents​

An automation can run an enabled custom Agent, or a managed Agent that advertises a manual trigger:

{
  "type": "action",
  "action": "run_agent",
  "agent_key": "ticket_reviewer",
  "mode": "wait",
  "instructions": "Review {{issue.key}} and recommend the next action.",
  "output_variable": "review"
}

wait runs the Agent inside the automation worker. The next step can read the result through {{review.*}} or {{variables.review.*}}; an Agent failure fails the parent automation.

detached queues the Agent, stores its run handle in the output variable, and lets the parent continue. Use an Agent run completed trigger to consume the eventual {{agentRun.output}}, {{agentRun.status}}, or {{agentRun.error}}. The listener must enable Allow automation and AI events to start this rule.

Project scope is a hard tool boundary for an Agent started by a project rule. Its ticket search, lookup, create, update, comment, and link tools cannot target another project, even though the underlying automation service account is an organisation administrator.

Completion listeners are also exact-scope. A project listener receives Agent runs from that project only. An organisation-level listener receives only Agent runs without a project; it does not aggregate project Agent completions.

Completion output is bounded to 10,000 characters. Larger values become {"truncated": true, "preview": "..."}. When that happens, nested values such as {{agentRun.output.reply}} are no longer present; use {{agentRun.output.preview}} or reduce the Agent output.

An Agent can call an automation with its List automations and Run automations tools. This direction has two independent gates:

  1. The Agent must use Allow direct writes, with Run automations set to Write directly.
  2. The target rule must enable Allow AI Agents to run this rule.

Agent calls are project-exact: a project Agent run can call a rule in the same project, while an organisation Agent run without a project can call a global rule. End-to-end encrypted ticket targets are rejected.

Automation and Agent chains share a maximum depth of three. Completion events and direct Agent invocations use stable deduplication keys so a retried terminal event does not create duplicate runs.

AI-authored ticket events​

Ticket changes made by Agent tools, chat workspace tools, and accepted AI proposals emit the same automation events as equivalent ticket writes. Rules must enable Allow automation and AI events to start this rule before those events can start them. This switch is separate from direct Agent invocation so each boundary can be enabled independently.

Recipes​

Comment reopens a closed ticket

Trigger: work_item_commented

Steps:

[
  {"type": "condition", "condition": "issue_fields", "field": "status_category", "operator": "equals", "value": "done"},
  {"type": "action", "action": "transition_issue", "target_status": "in_progress"}
]

All subtasks done closes the parent

Trigger: work_item_transitioned

Steps:

[
  {
    "type": "branch",
    "branch": "parent",
    "steps": [
      {"type": "condition", "condition": "related_issues", "relation": "subtasks", "mode": "all", "status_category": "done"},
      {"type": "action", "action": "transition_issue", "target_status": "done"}
    ]
  }
]

PR created moves ticket to review

Trigger: development_event

Steps:

[
  {"type": "action", "action": "transition_issue", "target_status": "in_review"}
]

Development triggers are connector-backed. The flow validates and appears in the UI, but execution requires a registered connector adapter.

Stale blocked tickets move to triage

Trigger:

{"type": "scheduled", "every_minutes": 1440}

Steps:

[
  {"type": "action", "action": "lookup_issues", "tql": "status = blocked AND updated < -7d"},
  {
    "type": "branch",
    "branch": "lookup_issues",
    "steps": [
      {"type": "action", "action": "comment", "body": "Blocked for more than a week."},
      {"type": "action", "action": "transition_issue", "target_status": "todo"}
    ]
  }
]

Scheduled cleanup archives done tickets

Trigger:

{"type": "scheduled", "hour_utc": 2}

Steps:

[
  {"type": "action", "action": "lookup_issues", "tql": "status_category = done AND updated < -30d"},
  {
    "type": "branch",
    "branch": "lookup_issues",
    "steps": [
      {"type": "action", "action": "transition_issue", "target_status": "archived"}
    ]
  }
]