Automations

An automation moves an issue’s status for you when something happens in git, when the last open subtask of an issue is resolved, or when an issue is marked as a duplicate of another. Close on merge is the common one: merge the pull request that fixes ACME-12 and ACME-12 is Fixed, with a line in its history that says why.

Automations belong to a project. Project Admins create and change them; everyone who can read the project sees them and what they did. They need a GitHub or GitLab repository linked to the project for the git triggers; Resolve parent and Close duplicates work without one.

Every project starts with one rule already on: Close duplicates. Mark ACME-14 as duplicates ACME-9 (or ACME-9 as is duplicated by ACME-14) and ACME-14 moves to Duplicate, while ACME-9 stays open as the one people keep working on. It only closes an issue that is still open, and it does nothing to the issue being duplicated. Switch it off, change its status or delete it under Project settings → Automations like any other rule.

What can fire a rule

Each rule does one thing: it sets the issue’s status.

Conditions

A rule can ask more before it acts. It checks the issue as it is when the event arrives, not as it was when the event was sent.

• Status category - only issues that are, say, not started yet.
• Issue type - only bugs.
• Closes the issue - the pull request or commit says Fixes ACME-12 or Closes ACME-12, not just ACME-12. Pull request merged acts only on these unless you say otherwise.
• Into these branches - a merge into main or release/*. Left out, the repository’s merge branches count (its default branch, unless the repository says otherwise).
• No other pull request still open - when ACME-12 has two open pull requests, the first merge leaves it alone. A pull request closed without merging counts as abandoned, not as unfinished work, so it never holds the issue open. On by default for Pull request merged.
• No other open pull requests - a pull request closed without merging moves the issue back only if nothing else is still open for it. On by default for Pull request closed.
• Draft or not, to the default branch, and at least this many subtasks.

Templates

Six ready-made rules. Each fills in the first fitting status of your project. Close duplicates is already on in every project; the other five are offered and never switched on for you:

The order rules run in

Rules for the same trigger run in their order, top first. The first one that changes the issue ends it: two rules never fight over one issue. A rule that would set the status the issue already has does nothing.

A change an automation makes never fires another rule. If Close on merge resolves the last subtask of ACME-10, ACME-10 stays as it is; if Alex Lee resolves that subtask by hand, Resolve parent runs.

What you see afterwards

• In the issue’s history, the change is made by Nothing Left Bot and names the rule and its cause: Nothing Left Bot · Close on merge · Status: In Review → Fixed, because acme/web#42 was merged by @alex-lee. Updated by on the issue still names the last person who changed it.
• In the run log, every time a rule looked at an issue: what it changed, or why it left the issue alone (already in that status, a condition did not hold, the project is archived, its status no longer exists). Kept for 90 days.
• In notifications, the usual status changed or resolved, except for the person whose git work set it off: merge the pull request yourself and you are not told about the change it caused. See Notifications.

Testing a rule

A dry run on one issue says what the rule would do to it now - would move ACME-12 from In Review to Fixed, or why it would leave it alone - and changes nothing.

When things change around a rule

• You rename a status: every rule that sets it follows the new name.
• You archive or delete the status a rule sets: the rule is marked status missing and skips until you point it at another status.
• The project is archived: rules skip, and the run log says so.
• A webhook delivery is replayed: rules run only when the replay asks for them, and only for what the replay itself changes - a pull request already recorded as merged does not count as merged again, while commits it carries do. Reading in a repository’s history when it is first linked never runs them.

Limits

The free plan allows 10 automations per project. See Limits and billing.

Asking an agent

list_automations, create_automation, update_automation, delete_automation, test_automation and list_automation_runs do all of this through MCP; the why-did-it-change prompt explains an issue’s recent changes, automated ones included.