Automations

Tenant-defined automation rules. Every audit event (task.created, task.status_changed, comment.created, and so on) is matched against active rules, and matching rules run actions such as set field, apply label, notify user, or call webhook. The v2 builder is dropdown-driven end to end, with no typing of field names or event strings.

• Template gallery: six pre-canned workflows (auto-label, ping on new task, webhook on DONE, and more) with zero typing to instantiate
• Trigger dropdown: common audit patterns (task.created, task.status_changed, project.*, comment.*) with human-readable labels
• Actions: set_field (Task.status/priority from an enum), apply_label, notify_user, and call_webhook, each backed by a picker rather than a text box
• Per-rule run log with status, duration, and error message

• Rules run in the order defined. Use distinct trigger patterns to avoid loops.
• Webhook delivery retries with exponential backoff; failed deliveries surface in /settings/webhooks.
• set_field is limited to a whitelist (Task: status/priority/title/description/dueOn/startsOn; Project: status/name/ownerId). Other fields are intentionally unreachable from automations.

1. 1Click From template to pick one of the six pre-canned workflows (recommended).
2. 2Or click Custom, pick a trigger from the dropdown, then add one or more actions, each configured via dropdowns.
3. 3Toggle the power icon on the list to enable or disable a rule without deleting it.
4. 4Review the run log to confirm the rule fires as expected before you rely on it.

Why can only certain fields be set by set_field?

Automations bypass most guardrails to stay fast. The whitelist (status/priority/title/description/dueOn/startsOn on Task; status/name/ownerId on Project) is what we verified is safe to let rules write. Everything else needs the regular API path so its own validations run.

Can I edit a template?

Create from a template, then edit the resulting rule like any other. The template is a construction aid, not a runtime link.

Why has an automation triggered itself repeatedly?

Rules run in the order they are defined, and a rule whose action matches its own trigger will loop. Give each rule a distinct trigger pattern so an action cannot satisfy the condition that started it.