Without rules, every task runs according to its scheduled date, regardless of what happened previously. With rules, a flow can respond to responses and completed tasks. There are two types of rules:
Branching: Different tasks are triggered based on the response provided within a task. For example, someone who chooses a company car will receive different tasks than someone who opts for a public transport pass.
Waiting: A task only begins once another task has been completed. For instance, the accounting department will only order a company credit card once it has been approved.
Rules are defined within a flow template, not within an individual task template. This allows the same task to behave differently depending on the flow template in which it is used.
Where to set up rules
Open the flow template and click the pencil icon in the row for the relevant task.
Switch to the "Rules" tab.
Click "Add new rule" and select the "Rule type."
Configure the rule and click "Save." Afterward, be sure to save the flow template as well.
Which task you open depends on the rule type:
Branching: the task in which the question is asked
Waiting: the task that is to wait
A task can include a branch for each field, as well as an additional waiting rule.
Tasks based on a response
Rule type: "Different tasks are triggered depending on how a field is filled out."
Under "Field," select the question to which the flow should respond.
Define a condition—for example, "If the answer is 'company car'."
Under "Then," select the tasks that should be triggered in this case.
For each additional response, click "Add another condition."
Example from "Sales Onboarding": In the "How do you get to work?" section, the employee selects their "mode of transport."
Depending on the answer, : | the following tasks are triggered: |
Company car | "Upload driver's license," "Order company car," "Hand over company car" |
Commuter pass (Jobticket) | "Order commuter pass" |
Company bike | "Request company bike" |
These tasks remain on hold until the answer is provided. Once it is, only the relevant tasks are triggered; the others never start. For instance, if Anna selects "Company car," the task "Order commuter pass" will not be assigned to anyone.
The available conditions vary depending on the field. The examples starting with "contains" are taken from "Development Onboarding":
Condition | Purpose | Example |
is | an answer selected from a list | “Means of transport” is “Job ticket” |
contains | one of several selected (checked) answers | “Additional equipment” contains “Company mobile phone”: “Set up company mobile phone” is triggered |
does not contain | an answer that has not been selected (checked) | “Which tools are you already familiar with?” does not contain “Docker”: “Introduction to Docker” is triggered |
is filled in | a field that contains an entry | “GitHub username” is filled in: “Invite to GitHub organization” is triggered |
is empty | a field that remains empty | “GitHub username” is empty: “Create GitHub account” is triggered |
Whether a field remains empty is only determined once the task containing the question has been completed. Until then, a task based on the “is empty” condition will not be triggered.
Waiting for other tasks
Rule type: "This task starts only after another task has been completed."
Select one or more tasks under "Wait for."
If you select multiple tasks, specify under "Start when" whether "all of them are completed" or "any one of them is completed."
If you would like an additional period of time to pass afterward, enable "Wait for a few days after" and enter the "waiting period."
Setting | Example | What happens |
All of them | "Create developer accounts" waits for "Set business email address" and "Set up laptop" | IT will only create the accounts once both tasks are completed. |
One of them | "Order company credit card" waits for "Approve company credit card" and "Approve company credit card (Sales Management)" | Approval from either the manager or Sales Management is sufficient. The other approval request remains open. |
With a waiting period | "Draft employment reference" waits 7 days for the "exit interview" | The reference is generated one week after the interview. |
The scheduled date for the waiting task remains unchanged. If the other task is completed at a later time, the waiting task will start correspondingly later.
Note: If a task is waiting for a task from a branch, it will only start if that branch is actually active. The "Rules" tab will alert you to this.
Tasks that wait automatically
Some tasks wait even without an explicit rule. This is built into their task template; you cannot change this behavior within the flow template.
A text-based response: For an "Order laptop" task, the IT department needs to know the operating system the employee selected for their "preferred laptop." Consequently, IT cannot complete the task until this response has been provided.
An optional text-based response: For a "Welcome conversation" task, the manager can see the "message for us" provided in the "Is there anything else you would like to share with us?" field. Since this input is optional, the task does not wait for it; if it is missing, the field simply displays "(no response yet)."
A form requiring multiple signatures: If several people need to sign in sequence, each person can only sign once the previous person has finished.
Keeping track of rules
In the list view: The "Conditions" column uses small icons to indicate whether a task involves branching, waiting, or utilizing a response. Clicking on an icon provides a full-sentence explanation of when the task is triggered and what depends on it.
In the flow diagram: Each task is a card, and each dependency is a line. A branch begins at the response that triggers it—for example, "company car." If you click on a card, you will see only its connections. Using the "Adjust view" option, you can hide specific types of items—for instance, all tasks that have no dependencies.
Clicking the pencil icon on a card (“Edit rules”) takes you directly to the “Rules” tab for that task.