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 (depending on which model the Workflow Template is for - but not on other models),
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.
Click the image to view it enlarged
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 End Users who are Decision Makers), rather than multiple extra steps.
So, for example, you could have a Workflow Template like the following (shown in 2 screenshots to show the 2 different conditions as stated in the tooltips):
Click the images to view them enlarged
If this Workflow Template is applied to a Company that has Module X but is not in the Enterprise Tier, the Workflow will look like this:
... whereas if this Workflow Template is applied to a Company that does not have Module X but is in the Enterprise Tier, the Workflow will look like this:
📌 Important to note
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.
📌 Important to note
Step conditions on Workflows targeting models other than Company or End User cannot be set for records on that target model, only on the whole Workflow or parent steps.
For example, whereas a Company Workflow could have a step condition that's "when a Company matches filter/criteria", a Workflow on the Asset model cannot have a step condition that's "when an Asset matches filter/criteria".
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 steps that are not dependent steps, 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"
This is not available if your Workflow is for a model other than Company or End User
Create a rule or match a filter, but this time referring to the Workflow 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, there is an additional option - 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 in some circumstances, 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: