Build a task automation by picking options, not drawing joins

State the decision in one sentence

Before opening an editor, write the rule in ordinary language: When a task changes, if its status is Blocked, add the review-needed tag; otherwise leave it alone. This is a narrow, observable behavior. It avoids guessing who should own an incident, setting every blocked task to critical, or sending messages before the destination is understood.

Specify why the rule exists. In this fictional team, a coordinator reviews tagged work once each morning. The tag is useful because it joins an existing human routine. Without that routine, automation would merely create more metadata. A good rule connects an event to an accountable next action; it does not need to perform every step itself.

Also decide what should not happen. A blocked task that becomes unblocked will not automatically lose the tag in this rule. The current action set includes adding tags, not removing them. Choose a name such as review-needed that tolerates that limitation and have the reviewer clear it deliberately when appropriate. This is more honest than describing the tag as a perfectly synchronized live status.

Know the current options before designing around them

Critical Path exposes two event triggers: a task being created and a task changing. Conditions can inspect task status, priority, Matrix lane, owner, tag, or overdue state. The contains operator is available for tags; other fields use the relevant equality choices. These options describe the current implementation, not an unrestricted integration platform.

The available actions are Set task status, Set priority, Move Matrix lane, Assign owner, Add tag, and Enable follow-up. Owner choices come from the workspace. Enable follow-up turns on the task's email follow-up configuration and supplies default offsets when none exist; it does not select recipients or send immediately. Follow-up still needs a due date, explicitly selected eligible workspace recipients, and working email delivery. Ordinary reminders and their Slack routing are separate controls.

An overdue condition is evaluated when its workflow event occurs. It does not make the rule a clock-based trigger that fires at the moment the deadline passes. If your requirement is a timed reminder, configure the reminder controls and verify their schedule instead of treating a task-change rule as a timer.

Build the blocked-work rule in the guided editor

Open Automations and choose a recipe or New guided automation. Recipes start as drafts, not active policies. Give the workflow a descriptive name such as Flag blocked work for review. A useful name describes the behavior and scope; Automation 4 will be difficult to recognize when you later investigate an unexpected change.

Use the option controls to select the task-change trigger and the condition Task status is Blocked. On the matching branch, add the Add tag action with review-needed. Give that branch an ending such as Review requested. Keep the Otherwise branch as an explicit ending such as No change needed. The guided controls wire the sequence; you do not need to draw arbitrary connections.

Read the complete sentence back before previewing. Check whether every blocked task really belongs in this rule, or whether another condition should limit it to an owner or tag. Start with the narrowest useful scope. Add complexity only when a real counterexample requires it.

1. Choose the task-change trigger.
2. Set the decision to Task status is Blocked.
3. Add review-needed on the matching path.
4. End the matching path with Review requested.
5. End Otherwise with No change needed.
6. Resolve any validation messages before previewing.

Preview both branches with fictional and real inputs

The editor offers example data that is never inserted into the workspace, as well as your active tasks. Preview calculates a route and its proposed changes without changing the selected task or calling a messaging provider. A real-task preview gives better context, but it is still a simulation rather than a live delivery test.

Inspect both a matching and a nonmatching case. For the fictional blocked task, expect the matching path, one added tag, and Review requested. For an in-progress task, expect Otherwise and no task-field change. Also preview a blocked task that already has the tag: no additional tag is needed, but the route can still finish normally.

Examples are constructed around the first decision. If you add multiple conditions, do not assume the example pair covers every branch. Select suitable real tasks for read-only preview or reason through additional inputs. A successful preview confirms one route for one input, not exhaustive proof that every possible task will behave correctly.

Activate only after checking the impact

Review the impact summary and the current preview, then choose Activate. The editor requires a current completed preview before activation. If the workflow, selected test data, or relevant team data changes, preview it again. This check reduces accidental activation of a configuration you have not just inspected.

Activation applies to future matching task events. It does not sweep through every existing blocked task immediately. To verify live behavior, use a suitable low-stakes task and deliberately make the relevant change, understanding that this is a real workspace mutation. Inspect the task's tag and history and the workflow's recent runs. Do not use confidential customer work as a disposable test fixture.

Several active workflows can affect the same task in sequence, and a later workflow may see changes made by an earlier one. Review overlapping rules together. One workflow that sets a priority and another that resets it can produce confusing outcomes even when both previews looked reasonable in isolation. Keep policies small, distinguish their scopes, and inspect the final task state rather than counting runs as success.

Pause, change, and re-preview deliberately

Pause a rule when its policy is no longer appropriate or before changing its behavior. The editor also pauses active workflows when behavior is edited. Re-preview before reactivating. Pausing stops future executions; it does not remove tags, restore prior owners, or undo statuses already changed by the rule.

When removing a decision, the editor asks which branch to retain. Read that choice carefully because the other path is removed from the workflow. Treat this as a policy edit, not visual housekeeping. Record the reason for a substantial change in the workflow description so another operator can understand its intent.

Loops and arbitrary joins are not enabled; each path needs an explicit ending and is limited to 48 steps. These boundaries favor inspectable rules. If a procedure needs dozens of conditions, split the operational problem before building more steps. A short rule with a clear owner and a verifiable outcome is usually easier to maintain than a comprehensive diagram nobody trusts.

Common questions