Summary
When configuring a Workflow Template, you can make a Workflow step dependent on a previous step, rather than them being independent of each other
This means:
You enforce the order in which steps occur (a child step can't overtake a parent step if it's delayed)
The timings (and hence due/send dates) of child steps now relate to when their parent steps were completed, rather than when they were activated
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 dependencies ⬅️ 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 Scheduling your Workflows and Workflow step timings. If you haven't yet, please go through those articles before this one 🙂
What are step dependencies?
Often, when scheduling actions in a Workflow, you'll want a step to take place only after another step has occurred.
In the examples of simple step timings we looked at in the previous article, all the steps were independent of each other. This meant that when all the steps were activated by applying the Workflow Template to a Company or End User, they were all assigned their due dates, and if one step was completed late, it didn't affect the due dates of the others.
In contrast, with step dependencies, you make a hierarchy of parent and child steps (and you could have many levels if you like, with grandparent and grandchild steps etc.). The two main consequences are:
You enforce the order in which steps are scheduled/completed - parent before child
The timings of child steps now relate to their parent steps, rather than when they were activated (when the Workflow was applied)
Note that it's also possible to add in step conditions, which further influence when steps occur. We'll go over conditions later in this article series, but firstly in this article we'll just consider dependent steps without conditions.
Here's an example of a dependent step (a task step in a Project). The indented "Send follow-up email with next actions" is a child of the "Kick-off call" step.
The dependent step is only scheduled after its parent step is completed. (If a parent step is a task, like in this example, "completed" means the task was set to done or ignored; or if it’s an email, that the email was either sent or stopped.) The step timing of the dependent step counts from the parent step completion.
Let's see what this looks like in practice when we apply the Workflow Template.
You can see that the first two steps - the ones completely aligned to the left - have their due dates assigned as you've seen before. But the indented dependent step is not yet scheduled, because we don't yet know the date the parent step will be completed.
Once the parent step is completed (here, earlier than the due date, on 20th January), the dependent step is scheduled, with its due date now filled in:
Let's take a look at this with a different example - email steps in a Sequence:
If we apply this to an End User:
The first email is sent right away (as it as sent to send ASAP)
Once the first email is sent, the second email is created as a scheduled email (scheduled to send 1 day later)
The third email is not yet created as a drafted/scheduled email because its parent isn't completed (the second email hasn't sent yet), but an estimated send date (of 1 day after the second email) is shown
You can see this here:
Why use step dependencies?
There are many cases where you'll want to ensure steps occur in a specific order.
For example, you might want to:
review a Company's usage, then
call them to discuss your findings, and then
write up the call notes.
As you can't call before doing the review, and you can't write call notes until after the call, it makes sense to make these dependent steps, so they won't go out of sequence if an earlier step is delayed.
It also may be that, when setting up the scheduling, you simply find it easier to think about step timings in terms of, for example, "I want this email to be sent 2 days after the previous email" rather than "I want this email to be sent 5 days after the Workflow is applied", and you can achieve this using dependent steps.
Another factor to consider is that you may wish to avoid having a series of scheduled draft emails being created straight away (potentially cluttering your End User Profiles), and prefer them to only be created/scheduled as the earlier steps are completed.
How to set up step dependencies
To position steps like this in a Workflow, you can right click a step that you would like to be a parent and select "Add Dependent Step", then enter the details of the new dependent (child) step.
Alternatively, you can make an existing step a dependent step by dragging it to the right, under the desired parent. Mouse over the step you want to move so the icon with four arrows appears, and click on that to drag and drop the step.
Note that it does not have to be a purely linear sequence of step A —> B —> C. In the example shown below, once the initial step is completed, both the "Call End User" and "Internal review meeting" steps are scheduled, and each of those has its own dependent step.
Remember that making steps dependent affects the step timings - we are now counting days from each step's parent step completion, rather than from the date the Workflow Template was applied.
It’s possible to add rule-based step conditions, so a dependent step is activated based on a specific parent step outcome. We’ll talk more about step conditions later in this article series.
Next ...
So you've seen how you can add timings to step details, and make steps dependent on other steps if required. The next element to sequencing steps is rule-based conditions, which we introduce here.