Work management
Automation
When this happens, if these are true, do that — and the one rule that stops it eating itself.
A rule has a trigger, any number of conditions, and one or more actions. New bugs get assigned to whoever is triaging. Anything moved to *Blocked* gets a label. Work with no estimate gets a note asking for one.
Automation does not trigger automation
A change made by a rule is not an event other rules can see. Without that, two rules that disagree — one assigning bugs to a triage queue, another assigning unassigned work to its reporter — will bounce an item between them until something gives out. Every automation engine ships this bug at least once, and the ones that solve it with a recursion limit have only made it slower.
The cost is that rules cannot be chained. That is deliberate: if chaining is ever wanted it should be explicit — a rule naming the rule it hands to — rather than emergent from two people writing rules that happen to overlap.
Conditions are ANDed
An *or* is a second rule. That is easier to read, easier to switch off on its own, and easier to explain when somebody asks why their item was touched — the three things that decide whether automation is trusted rather than switched off wholesale.
What is refused
- A rule that reacts to what it changes. Reacting to an assignment by assigning would fire on somebody's edit and immediately overwrite it, which reads as the edit not saving.
- A condition with nothing chosen. It can never be true, so the rule can never fire — and it looks configured.
- An action with nothing to do, and a rule with no actions at all.
- A transition condition on a trigger with no transition — asking whether something moved into a state only means something on a state change.
When rules disagree
Two rules setting the same field is not refused — it is often intentional, and the combination only exists at run time. The last rule wins, and the conflict is reported in the run log. Silently picking one is how somebody spends an afternoon working out why their rule does not work when it is running perfectly and being overwritten.
When a rule fails
Rules run after the change that triggered them has committed, never inside it: somebody moved a card, and whether an automation succeeded is not their problem. A rule that throws does not roll back their edit.
A rule that fails five times in a row is switched off and says why. One that fails silently forever is worse than one that stops. Editing a rule clears the count, because whatever was wrong may be what was just fixed.
The run log
Every firing is recorded with what it did, in words — including the ones that matched and found nothing to change, which is the answer when somebody is certain their rule is not running. Without a log, the answer to *what touched this item* is "a rule, probably", and that is how people come to distrust the feature and turn it all off.
An automated change is attributed to the rule, not to the person whose edit triggered it. Putting changes in somebody's name that they did not make and cannot explain is worse than having no attribution at all.