Workflow automation

Rules that watch your work items and act on them: when priority changes to urgent, post a comment. Set them up once and the engine handles the rest.

Plan: Pro and above

What you can do

• Create rules that fire when a work item changes.
• Match on priority, state or assignee, using changed to, changed from or equals.
• Have a matching rule post a comment on the work item.
• Enable or disable a rule with a toggle, without deleting it.
• See the last executions, with a success or failed badge per run.

Getting started

Automations live at Workspace settings → Automations.

Turn the engine on (one-time, per workspace)

Rules do nothing until the engine is connected and events are being forwarded to it. Expand Activate automations — one-time setup at the top of the page and do both steps.

1. Connect the engine. The engine needs an API token so it can act on your behalf.

1. Go to Settings → API Tokens, create a token, and copy it.
2. Come back to Settings → Automations, paste the token into the box in step 1, and click Connect.

A green Connected badge appears. The token is sent only to your own server and is never shown back to you. Paste a new one at any time to replace it.

2. Forward events to the engine. The engine reacts to a webhook, so the workspace has to send it one.

1. Copy the webhook URL shown in step 2 of the setup panel (there is a Copy button).
2. Go to Settings → Webhooks → Add webhook.
3. Paste the URL, enable it for Issues (and Comments if you want comment events), and save.

That is it. Enabled rules now run whenever a matching work item changes.

📷 Screenshot: The Automations settings page with the one-time setup panel expanded, showing the token box and the webhook URL.

Create a rule

1. On Settings → Automations, click Create Rule.
2. Give the rule a name — this is what you will see in the list, so make it describe the outcome ("Flag urgent items to the team").
3. Build the condition from three inputs:
   • Field — Priority, State or Assignee.
   • Operator — Changed to, Changed from, or Equals.
   • Value — what to compare against. For priority use urgent, high, medium, low or none. For state, the state's name. For assignee, the member's ID.
4. Under Action: Post Comment, type the comment the rule should leave.
5. Click Save Rule.

The rule appears in the list, summarised as When priority changed_to "urgent" → post_comment, with an on/off toggle and a Delete button.

📷 Screenshot: The rules list showing a rule with its condition summary, enable toggle and delete button.

Triggers and actions, precisely

The rule builder exposes a deliberate slice of the engine. Here is what each layer actually supports.

What the rule builder creates: a rule that fires on a work item update, tests one condition, and runs one action — posting a comment. That is the whole of the UI.

What the engine supports (reachable through the automation API, not the rule form):

So update_field and send_webhook genuinely work — but today you have to create those rules through the API. The settings page only builds comment rules.

Watching rules run

The Recent Executions panel below the rules list shows the latest runs: when it fired, the event action, and whether it succeeded or failed. If a rule's action errors — a bad field name, an unreachable webhook — the run is logged as failed with the reason recorded.

Tips

• Start with the rule disabled, watch one real change go through, then enable it. A noisy rule that comments on every update gets old fast.
• Changed to is almost always what you want. Equals matches the item's current value, which will be true on every subsequent update too, so it fires repeatedly.
• Scope narrowly. Rules created from the settings page apply to the whole workspace, so a condition like priority equals high will comment across every project.
• If nothing happens, check the setup panel first: no Connected badge, or no webhook registered, means no rule can ever run.

Limits & good to know

• Both setup steps are required. A rule with no engine token or no webhook silently never fires.
• The rule form supports one condition and one action. Multiple conditions and multiple actions exist in the engine, but not in the form.
• Rules built in the UI only listen for updates. Creating a work item will not trigger them.
• A rule cannot be edited after creation — you can toggle it on and off, or delete it and build a new one.
• The Value box is free text and is not validated. A typo just means the rule never matches.
• Actions the engine takes (a comment, a field change) generate their own events. A short loop guard stops an item from re-triggering rules immediately after a rule acted on it, so chained rules will not run away — but do not design rules that depend on one triggering the next.
• send_webhook will only call public addresses. URLs that resolve to private, loopback or link-local addresses are blocked.
• The incoming webhook is signature-checked against your workspace's webhook secret. Events that fail the check are rejected.

Related

• Custom fields
• Reports
• Core concepts