Summary
When scheduling steps in a Workflow Template, one of the places you can apply conditions is on individual steps
Step conditions can automatically activate steps in response to data, although not deactivate them
You can add step conditions based on properties of the Company or End User (whichever the model of the Workflow is), properties of the Workflow, or properties of the parent step (if it's a dependent step)
Who is this article for?
Planhat builders (e.g. CS Ops), designing Workflow Templates for their team
Series
This article is part of a series on scheduling Workflows:
Workflow step conditions ⬅️ You are here
It is strongly recommended to read these in order, as they build in complexity, and later articles refer back to earlier ones.
Article contents
Click below to jump to the relevant section:
📌 Important to note:
This article assumes you have read the earlier articles in this series, and are familiar with basic step timings and step dependencies. If not, please go through those articles (links above) before this one 🙂
What are step conditions?
After Workflow entry/exit criteria and group conditions, the third place you can apply rule-based conditions is to individual steps.
Once set up, step conditions are indicated in Workflow Templates by the orange "conditions" icon you saw with group conditions, but this time you will see it on the step level.
Step conditions are a way to activate a single specific step based on a condition (matching a rule or a filter), rather than applying a condition to a group of steps. This can be useful if you have, for example, one extra step (e.g. meeting) for a particular type of customer (e.g. Enterprise Customers, or Decision Maker End Users), rather than multiple extra steps.
One key difference from group conditions is that while you can use group conditions to expire steps when the condition no longer matches, that is not possible in step conditions. As soon as Planhat detects the step condition is met, the step is activated, and the step won't be deactivated even if the condition then stops being met.
Step conditions, step dependencies and step timings
🤓 Tech alert! This next section is quite advanced. If you're building Workflow Templates with step conditions and dependencies, make sure you understand how this affects step due dates. If you're not creating/editing Workflow Templates, just using Workflows, you can skip this part, and jump to "Why use step conditions?". ⚠️
An important point to note is that step conditions affect step timings (due/send dates):
When the step with a condition is a parent/independent (fully left-aligned) step, the due date or send date will come from counting the number of days after the step is activated by the condition being met
So in the example below (with no group conditions), if the Workflow Template is applied to an Enterprise Company, the highlighted step will be activated right away and will have the due date of 7 days later. If the Company is not Enterprise, this step will not be activated. Simple!
When the step with a condition is a dependent step (indented), the due date or send date will always be determined by counting the number of days after the parent step is completed, the same as a regular dependent step, but the step itself will only be activated once the condition is met. This means:
If the condition is met before the parent step is completed (e.g. if the condition is something static, such as End User type or Company tier), this is all very straightforward - either it will behave like a regular dependent step if the condition matches, or it will never match the condition and never be activated
However, if the step condition is met at a later date (e.g. 2 weeks after the parent step is completed), because the date timing still counts from parent step completion, when activated, the dependent step could potentially be given a date in the past (be overdue) if it's a task, or send immediately if it's an email (if the scheduled due date was in the past)
If we take the example below, the Module X training step will always be scheduled for 3 days after the parent "Introductory training" step is completed. If the Company has Module X to begin with, this is all very simple. But if the Company gets Module X a week later, this step would be activated then, with a due date in the past
When a step in a Sequence is a dependent step and has a condition, it will be labelled "Multi-factored timing!", and if you put your mouse over the "i" icon, you will see a tooltip explaining this situation:
Why use step conditions?
The main types of use case for step conditions are:
Similar to group conditions for different customers, but you only have one or two extra steps rather than a whole group - for example:
You have an extra training session (task step) if the Company belongs to the Gold Tier filter
You send an extra email (email step) when the End User is an Admin
You have a Salesforce integration meeting when the Company's tech stack (custom field) includes Salesforce
You want an escalation task to happen if the Workflow is delayed
You want a step to be activated or not based on what happens with a parent step.
This is more advanced than having a standard dependent step without conditions. These step conditions based on properties of the parent step are especially powerful in Projects, as they enable your Project to change direction based on unexpected developments during the Project. For example:
You have a parent task step to carry out a discovery call with an End User, and if it is not completed within 7 days after the due date (because you haven’t been able to get through to the End User), a dependent step is activated that emails a questionnaire to the End User instead
You have a parent task step for the Account Owner (CSM) to integrate the customer's CRM (e.g. Salesforce or HubSpot) with your product. If this turns out to be more difficult than expected - let's say their CRM is heavily customised, or has become very messy over the years - you could toggle a custom "Escalate" field on the parent task step that activates a dependent step to bring in a Technical Account Manager to help with troubleshooting
How to set up step conditions
To set or edit conditions for a step, either right-click on it (in the blank space), or mouse over it and click on the icon of 3 vertical dots that appears, and select "Step Condition".
For parent steps (fully left-aligned), the options are like those you have seen for group conditions:
Create a rule (match criteria) or match a filter, referring to the Company or End User (depending on the model of your Workflow) - for example:
When Company Phase is equal to Onboarding
When End User matches filter "Decision Makers who haven't started a course"
Create a rule or match a filter, but this time referring to the Workflow model itself
For example, when a custom field "Escalate" on a Project is toggled on, activate an escalation step owned by the Team Leader
For a dependent step (any step that is indented, so not fully left-aligned), there is an additional option in the "Condition Type" dropdown menu - you can activate the step based on the parent step:
For parent tasks, activate the child step based on:
Outcome - when the parent step is "done", "ignored", or "not completed" within a specific number of days (counting from the parent task due date)
A criteria-based rule (e.g. a custom task field called "Escalated?") or filter on the task
For parent emails, activate the child step when the parent is "done" or "ignored"
As you can see in the screenshots, as well as specifying the step condition itself, you should choose whether whether the step should be hidden and excluded from Workflow completion rate before it's activated, or muted but shown and included in the completion rate. Generally you'll want to leave this on the default "hidden", as the step will only be activated for some customers, not every time the Workflow is run.
Further reading
If you would like to learn more about designing Workflow Templates and using Workflows, check out these articles: