Four ways a rule that reads correctly does the wrong thing. All four are cheap to avoid and expensive to discover on a live client.
Chains that don’t chain
The natural way to think is that rule A moves the task to In review, and rule B watches Status changed, so B runs next. It doesn’t. A status, phase or review status changed by an automation does not set off your Status changed, Phase changed or Review status changed rules.
Put the steps in one rule instead. An automation can run several actions in order, which is how the shipped rules move a task, mark it for review and share the video in a single step.
Blockers are the exception, and a deliberate one. A rule that sets or clears a blocker does fire your Blocker added and Blocker removed rules, because otherwise a blocker cleared by a rule would leave the deadline clock paused forever. That exception causes the next trap.
The action order that undoes itself
Clearing a blocker fires your Blocker removed rules, and the shipped set includes one that returns the task to To start. So a rule written as:
- Change status In progress
- Set blocker Clear blocker
ends with the task in To start, because the clear ran second and its own chain overwrote your status.
Write it the other way round: clear the blocker first, set the status last. Actions run in the order you list them, so the last action wins.
Rules that reach the client at the wrong moment
Everything that only moves a field is recoverable. Send email, Enable video sharing and Trigger webhook are not, since a client who received a cut cannot un-receive it.
Attach client-facing actions to the step that means you are finished, like a completed review subtask or a blocker you set by hand, rather than to a broad trigger like Video uploaded. Keep exactly one rule that emails a client, because two is how a client gets the same delivery twice. And while your review process is still settling, leave the send-to-client decision manual: Send to client is one click, so the rule saves the click rather than the judgement.
Testing on a real client
Create a client called Test, with its own internal code, and run every new rule through a task there first. The board behaves the same, and the alarms and status changes stay inside your workspace.
The test client only isolates you once you set your own address as its contact. A Send email action with the client recipient goes to the client’s configured contacts, so with an empty or real contact list the email leaves the building exactly as it would in production.
Trigger webhook stays live either way, because the endpoint is configured per workspace rather than per client. A webhook rule fires at your real endpoint even from a test task, so point it at a test URL while you experiment, or leave the webhook action out of the rule until the rest of it works.
When a rule surprises you, the task’s activity log names the automation that made the change, so you can find the rule instead of guessing at it: See who changed what on a task.
Warning: There is no run history you can browse for automations. The activity log on the task is the record, which is another reason to test on one task you control rather than watch the whole board.
What’s next
Build a board that fits on one screen. Most automation problems turn out to be workflow-shape problems.