Automation

This page is for administrators. Automation rules do routine work for you — "when this happens, and these things are true, do that" — without anyone writing code. Rules live under Administration → Automation.

What a rule is made of

Every rule has three parts:

Part	What it decides
Trigger	What starts the rule.
Conditions	Whether it should proceed this time.
Actions	What it does.

Triggers

• An event — an issue is created, transitioned, commented on, assigned, and so on.
• A schedule — the rule runs periodically, without waiting for anything to happen.
• By hand — you run it yourself from the rule's page.

Conditions

Conditions are a tree, not a flat list: you combine them with and / or and can negate any branch, so a rule can express "high priority and either unassigned or overdue" without contortions. A wide set of comparison operators is available — equality, ordering, containment, emptiness, changed/unchanged, and so on — with the ones offered depending on the field you're comparing.

Actions

The built-in actions cover the obvious ground: change an issue's fields, status, assignee or co-assignees, add a comment, link issues, send an email, call an outgoing webhook. Two of them shape the flow of the rule itself:

• Stop if — abandon the rest of the rule when a condition holds.
• Delay — pause, then continue later. Deferred steps are picked up when they come due, so "if still untouched after 2 days, escalate" is a single rule.

Start from a template

The rule form offers ready-made templates for common patterns. Starting from one and adjusting it is usually quicker than building a rule from scratch, and it shows you how the pieces fit together.

Actions and conditions from other features

Automation isn't limited to what the automation feature itself knows. Other features register their own actions and conditions, and those appear in the rule form automatically once the feature is enabled:

Feature	Adds conditions	Adds actions
Custom fields	Compare the value of a field by key	Set the value of a field
SLA	SLA breached; minutes remaining before breach; timer running	—
Service Desk	Approval status; CSAT rating	Start an approval

If a feature is disabled or unavailable, its conditions evaluate as not met and its actions fail with an error in the run log. A feature that has quietly stopped will not cause rules to fire wholesale.

Testing a rule

Two buttons, and the difference matters:

• Test — a dry run. Conditions are evaluated against real data, but actions only report what they would have done. Nothing is changed.
• Run — a real run, with real consequences.

You can also replay a past run from the log — useful when a rule failed because of something you've since fixed.

The run log

Every run is recorded: what triggered it, whether the conditions matched, which actions executed, and the error when one failed. When a rule "doesn't work", the log almost always says why — most often a condition that didn't match the data, or an action belonging to a feature that's switched off.

Sending email from a rule

The Send email action needs a mail transport, chosen on this page. Until one is assigned, rule email isn't delivered — the attempt is recorded in the delivery log. See Email → Assignments.

Loops and runaway rules

Rules change issues, and changed issues trigger rules. TaskFlow guards against that in two independent ways: it limits how deep a chain of rule-caused changes may keep triggering further rules, and it caps how often one rule may run against one issue within a time window. Both defaults are sensible; they're adjustable in Configuration → Automation limits if you have a reason.

Even so, when you write a rule that edits the same kind of issue it reacts to, add a condition that makes the second pass a no-op. The guards are a safety net, not a design.

Where to go next

• Features & settings — enabling features.
• Email — transports for rule email.
• Project configuration — the statuses and fields rules act on.