Building automation rules

Automation rules are if-this-then-that, scoped to a project. They run server-side, near-real-time, with no external dependencies.

The structure

Every rule has:

Trigger — what starts the rule. Task created, status changed, due date passed, comment added, custom-field updated.
Conditions (optional) — narrow the trigger. Only when priority is High.
Actions — what happens. One or many.

Worked example: bug triage

“When a task is created with the #bug tag, assign it to the on-call engineer, set priority to High, and post a notification in #bugs.”

Trigger:    Task created
Conditions: Tag includes #bug
Actions:    Set assignee → @oncall_rotation
            Set priority → High
            Post to Slack → #bugs

Rules like this one shave hours off triage every week without anyone having to remember to do it.

Triggers reference

Task created
Task updated — fires on any change; use conditions to narrow
Status changed — fires on transitions; can scope to specific from/to
Assignee changed
Due date approaching — fires N days/hours before due date
Due date passed — fires once at the moment a task becomes overdue
Comment added
Tag added / removed
Custom field changed — per-field, per-value
Schedule — cron-style, runs without a task event

Actions reference

Set assignee, status, priority, due date
Add or remove tags
Set or clear custom field
Move to section / project
Add subtask (with templating)
Post comment
Send Slack message
Send email
Trigger webhook (with custom payload)
Create related task

Loop protection

Rules can fire other rules. To prevent runaway chains, Lattica caps a single trigger event at 10 cascading rule executions. If you build something that hits the cap, the audit log marks the chain as truncated and emails the rule’s creator.

Testing

Every rule has a Test button that runs it against a sample task you select, without making any changes. Use it before activating — and especially before changing a rule that’s already live.