Creation rules and conditional branches
Creation rules turn a linear workflow into a process with decisions: a task —or a deliverable— is created only if certain conditions are met.
What they are
They're conditions you configure inside a workflow template so that a task or a document is created automatically when they're met. In the diagram, tasks with a rule are drawn with a diamond arrow and a different color, so you can see at a glance which parts of the flow are optional.
Where to configure them
Open the workflow template in Draft status.
Enter the full task-configuration view .
In the Creation rules section, click (+) to add one.
How a rule is built
A task can have condition groups. Each group:
- uses the Meet all (AND) or Meet any (OR) operator,
- contains conditions, and
- can contain child groups —that is, they nest: (A and B) or (C) .
Each condition compares a field of a reference task against a value, with operators: Equals, Not equal, Greater / Less, Greater or equal / Less or equal, Contains / Doesn't contain, Is empty / Is not empty. Fields can be:
- Task field: name, status, project, subproject, executed by supplier, requires acceptance or PO, estimated cost.
- Custom field of the reference task, including its list options.
- Other values: for now, the availability date.
Evaluate a field of the workflow itself
Leave the Reference task empty, pick the workflow field, and set the criterion and operator.
Evaluate a field of another task
Select the reference task, pick the field to compare (status, project, subproject, or additional field), and set the criterion and operator.
When they're evaluated
On workflow creation, each task with rules generates a decision point. It's evaluated when a task referenced by the condition is saved, or when a referenced custom field is answered or changed. If it's true, that branch's tasks are created —with their subtasks and deliverables. If it's false, the branch simply doesn't exist in that workflow: no cancelled task cluttering the board.
Common trap: the field that triggers the condition must be on a task created before the conditional branch, and that task must be set as the reference. If the field lives on the conditional task itself, the condition never evaluates.
Conditions on deliverables
The same AND/OR engine is used on required documents: a deliverable can be required only under a condition. It's what allows "the working-at-height form is only requested if the site is a tower."
Example
You can set a Final inspection task to be created when all installation tasks are Completed and the Project type field equals FTTH.