Automations

Tenant-defined automation rules. Every audit event (task.created, task.completed, 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.