Summary
When configuring a Workflow Template, you can use rule-based conditions to determine if and when:
A whole Workflow is applied or archived
A group of steps is activated and potentially expired
An individual step is activated
Conditions enable you to automatically respond to changes in data
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 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 🙂
Introduction
In earlier articles in this series on scheduling your Workflows, we've gone though how that you can set timings in step details, and make steps dependent upon another.
The next method you can use to determine when (and if) steps happen is via rule-based conditions.
This is where you can get really clever and make use of the data you've compiled in Planhat, to automatically activate or cancel steps, even while the Workflow is running, enabling you to quickly and easily adapt to changes in data. Conditions enable you to deliver a tailored, personalised service to your customers, whilst being efficient and "tech touch".
You can actually set rule-based conditions on three different levels within a Workflow:
The whole Workflow, via Workflow entry and/or exit conditions
Group conditions
Step conditions
We'll deep-dive into each of these in individual articles, covering the What, Why and How, but firstly, here's a quick summary.
Workflow entry and exit criteria
Determine if/when:
A Workflow Template is automatically applied to particular Companies or End Users (entry criteria)
A Workflow is automatically archived (exit criteria)
You can set entry and/or exit criteria (you don't have to set both)
If you do set both entry and exit criteria, they can be looking at different data
Entry/exit criteria can:
Be rules you build in the Workflow Template
Refer to filters you have built in the Data Module for the relevant data model (Company or End User) - using filters means you can incorporate multiple criteria together (e.g. identifying Admins who have not logged in)
These rules/filters can use static (field) data and/or calculated metrics (time-series data)
Example use case: automatically add all new Enterprise Companies to "Enterprise Onboarding" Project
Group conditions
You can set one condition per group of steps, which determines when the group is activated, and you can choose what happens if/when the condition is no longer met (e.g. expire all steps)
As with Workflow entry/exit criteria, the group condition can be a rule you build in the Workflow Template, or use a filter created for the relevant data model (Company or End User). Rules and filters can reference fields and/or calculated metrics
In addition, with group conditions it's possible to use a rule or filter looking at properties of the Workflow itself
Typical example use cases include:
Static groups - groups of steps activate depending on a customer characteristic, and then don't deactivate - e.g.:
In a Sequence - groups for different languages, so End Users receive emails in their preferred language
In a Project - a group that only activates for Enterprise Companies, giving them extra training sessions
Dynamic groups - you may hear this referred to as "Sequence milestones"
In a Sequence, groups referring to usage data, to follow an End User as they carry out a series of actions within your product, where each group of steps (typically emails) encourages the End User to carry out the next action
As soon as they meet a group's goal (carry out the desired action), any remaining steps in that group are expired, and the next group is activated
Step conditions
Use step conditions to automatically activate individual steps within a Workflow
Note that once steps are activated, they would not be deactivated if the condition stopped being met
Step conditions can be:
A rule or filter referring to the model of the Workflow Template (Company or End User)
A rule or filter referring to the Workflow
For a dependent step, also:
A rule referring to parent step outcome
A rule or filter referring to the parent task (another property e.g. a custom field)
Example use cases:
Send an extra email if the End User "Type" is "Main User"
Activate an escalation step if the parent task has a custom "Escalate?" field toggled on
Next ...
We're going to start by going through Workflow entry and exit criteria in detail, and then we'll get increasingly granular with group conditions and then step conditions.