Administration

Automation and its safeguards

Automation rules per space: triggers, conditions, actions, and the limits that stop loops and storms.

Automation rules

Open a space, Automation. An automation rule reads as one sentence: in these projects, when something happens, if these things are true, then do this. It applies to every project of the space or to the ones you pick. Automation rules are written by the people who manage the space's workflows (somebody who manages one project's workflows writes the automation rules that apply to that project alone), and run as the Automation account with that account's permissions in each project. There is no scripting; automation rules are built from the catalogue.

Triggers

Status changed, work item created, work item deleted, sub-item created, item linked, field changed, assignee changed, comment added, attachment added, work logged, due date coming up, sprint started or completed, version created, updated, released, unreleased or deleted, project created, SLA threshold, scheduled, manual, development event from Git, and incoming webhook.

Actions

Send e-mail, comment (internal or shared with the customer), edit or delete the comment that woke the automation rule, create work item, clone item, transition, assign (to a person, the reporter, the actor, the least busy of a pool, or nobody), edit fields, move under another item, link items, attach files from another item, add watcher, log work, release version, create a Google Drive file, send a Slack or Microsoft Teams message, send a web request, and if / else branches.

Web requests

The send web request action calls a server you name. It accepts http and https on ports 80, 443 or above 1023, follows no redirects, and gives up after 5 seconds to connect and 20 seconds to answer. Addresses inside the server's own network (loopback, private and link-local ranges, .local and .internal names, cloud metadata) are refused. A Slack or Teams message is sent under the same rules, over https only.

Incoming webhooks

An automation rule with the incoming webhook trigger gets a secret address under /api/webhooks/automation/. Another system POSTs JSON to it (up to 64 KB); the automation rule can run once, or for each work item named under workItems (or Jira's issues), up to 100. A wrong address and a switched-off automation rule both answer 404. Issue a new address to retire the old one.

Safeguards

  • Automation rules woken by an event run on two background threads, never inside the request that caused the event; only an automation rule a person runs by hand from the work item runs while they wait
  • A chain of automation rules deeper than 3 is stopped as a loop
  • One automation rule can run at most 500 times an hour, all automation rules together 5000; past that they are throttled
  • The same automation rule on the same work item more than 5 times a minute is stopped
  • An automation rule that fails 5 times in a row switches itself off and says why
  • Scheduled automation rules run at least 5 minutes apart and handle at most 200 items per run
  • Up to 10,000 events wait in the queue; past that an event is dropped and logged

Every automation rule keeps a log of its runs, each tied to the version of the rule that ran; its screen shows the newest 50.