Summary
Group conditions can be added to groups of steps in a Workflow Template, to automatically activate/deactivate them as required, when applied to a Company or End User
For example, in a Sequence, you could have groups representing actions for an End User to carry out in your product (milestones). Using group conditions referring to usage data, each End User automatically moves between groups (with the previous one deactivating and the next one activating), so they always receive the relevant instructional emails
In other cases, group conditions may refer to more static customer characteristics, such as Company segment or country, activating the relevant tasks/emails for those customers, so for each customer some groups may never be activated
You can even activate groups based on Workflow properties, such as "Escalated"
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 group 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:
What are group conditions?
In our article on Workflow structure/levels we talked about why you would use groups in Workflows.
As a reminder, groups are a way to organise steps into categories. For example, groups could represent different stages of a process (which you may hear referred to as "Sequence milestones"). Another typical example is having groups for different products a customer may have, or different countries they may be in.
As well as making things visually clearer, you can apply data-based conditions to each group to activate - and, if necessary, deactivate - its steps as appropriate.
You can spot group conditions in a Workflow Template by the orange icon next to the group name. Putting your mouse over the orange icon will show you a tooltip stating the group condition.
When you use group conditions, the step timings for parent/independent steps start counting from the point their group is activated, rather than when the whole Workflow begins. This is particularly useful if you have different groups being activated at different times in a customer pathway, such as in the example shown below. (Dependent steps still work in the same way you learned about previously - their due dates are dependent on their parent.)
Why use group conditions?
In the previous article in this series, you've seen how Workflow entry and exit criteria can be used to automatically apply or archive a whole Workflow, but sometimes you want to be a bit more granular. Using group conditions, you can activate/deactivate specific groups of steps within the Workflow.
The three main types of scenarios are:
You have groups associated with customer characteristics
For example, you could create groups corresponding to End User language (like one of the screenshots above) or country, or groups corresponding to different products/modules purchased, or groups corresponding to different Company Tiers. This can be considered like mini Workflows within the one main Workflow; indeed, an alternative setup would be for these to be separate Workflows rather than groups
Using conditions on this type of group means you can automatically send different emails or have different task steps depending on what's relevant to each specific customer - e.g. only send instructional emails for modules an End User has, or only send emails in their preferred language, or only schedule the extra training sessions for Enterprise Companies
Generally in these examples, the relevant group(s) are activated and not deactivated (as the customer characteristics don't change), and you typically do not expect a customer to eventually be part of all the groups
You have groups representing goals/milestones along a pathway
These are groups corresponding to a series of goals a customer should complete within your tool - e.g. if your software is a training platform, you might want a new End User to first log in, then create a quiz, then publish a quiz, and so on
Using conditions on these types of groups, generally using filters referring to usage data, means you can carry out the relevant steps (typically this is sending the relevant emails) depending on where the customer is along the pathway
As an End User moves between filters and so groups, the next group is activated while the previous group has any remaining steps cancelled. This is a fantastic example of how a Workflow can adjust dynamically while it's running, in response to changes in data
You have groups that apply to properties of the Workflow itself
Rather than looking at properties on the Company or End User, you can also activate groups based on something happening on the Project/Sequence itself - for example:
If the Project is delayed, activate "Escalate" group
If a custom "Priority" field on the Project is set to type "VIP", activate "VIP" group
There could be cases where the group is activated right at the start (a bit like it being an Enterprise Company), or over time in response to changes in data (a bit like the End User usage data example)
How to use group conditions
To add a group condition, mouse over the group, click on the three vertical dots that appear to the right of the group name, and then click "Condition".
To open/edit an existing group condition, you can either repeat the instructions above, or click on the orange "condition" icon.
You can define the condition to be when an Company or End User matches a specific filter (created in the Data Module), or a rule (criteria) that you define here. Like you saw with Workflow entry/exit criteria, the rule can refer to a field or a calculated metric. It’s only possible to state a single rule, so if you want to consider multiple criteria, build them into a filter, and then use the filter in the group condition.
It's also possible to define the condition based on a rule/criteria or filter on the Workflow model, rather than on the Company or End User.
Here are some typical examples:
As you can see in the screenshots, there are another couple of settings to be aware of when you set up a group condition.
Firstly, you define whether or not the group should be visible in a Workflow and count towards its progress contribution % before it has been activated (i.e. before the condition has been met).
To help you decide, think about whether the groups are likely to apply to all customers eventually, or whether you expect the Workflow to complete without all groups applying to all customers. For example:
If your groups are a pathway of goals/milestones, you expect each of those objectives to be met at some point, so you’d likely want to set it to "Muted but shown, included in workflow completion rate"
Whereas, if your groups are languages, each customer will stick in one group, as French emails will never be sent to a Swedish customer for example, so you should set this to "Hidden, excluded in workflow completion rate"
Secondly, you choose what you want to happen to remaining steps "When the group condition no longer matches": keep or expire any pending steps. This is how you can use group conditions to automatically cancel steps.
In the example where you have a Sequence with each group representing a goal along a pathway, you want to set this to "Expire" for each group, so that as soon as the End User achieves a goal and no longer meets the group criteria, any remaining (and now unnecessary) steps are cancelled (e.g. the Workflow doesn’t keep sending email reminders to log in, if the End User has now logged in).
Next ...
Now you're familiar with group conditions, we're going to get even more granular, and look at conditions on individual steps.