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, updated (an assignee change included), gets an attachment or a link — and so on.
• A schedule — the rule runs periodically, without waiting for anything to happen.
• By hand — you run it yourself with the Run button in the rule list.

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.
• Pause — 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

Above the rule list sits a Rule templates card with common patterns — clicking one drops a ready-made recipe into the form. Starting from a template 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 three independent ways: it limits how deep a chain of rule-caused changes may keep triggering further rules; it stops a rule from reacting to an event it caused itself, unless the rule's Allow self-trigger box is ticked; and it caps how often one rule may run against one issue within a time window. The defaults of the first and third guards 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.