This article is part of a series on Workflows:

Click below to jump to the relevant section:

In this article series, we go through many different elements of Workflows - from the differences between Projects and Sequences, to the component parts of Workflows (groups, steps and step details), how to create a Workflow Template, how to schedule when steps occur, and so on.

While we list various Workflow (Project and Sequence) use-case examples here, and show screenshot examples throughout the article series (e.g. here), in this article we're going to show and talk through a couple of typical examples of Workflows to give you some more inspiration. This will bring together topics discussed in further detail in other articles.

Projects are a great way to organise a series of tasks. Although Projects can be used for lots of different use cases, and apply to either the Company or End User model, here we're going to focus on a Company Onboarding Project.

In this particular example, we're going to demonstrate having different audiences for different steps, sharing steps to the Portal, and simple dependent steps.

Click the images to view them enlarged

Let's zoom in on some key elements:

The first step is internal - it's a task to be completed by you and your teammates, rather than with or by the customer.

The groups/steps after that are shared to the Portal, for your customer to view. In this example, they are a combination of:

You can see different Conversation Types (shown in the "Type" column of the table) have been used to distinguish between the calls and the homework tasks (customer to-dos).

All of these task steps are shared in the Portal - as you can see by the blue "YES" in the "Shared in portal" column - so the description of each step in the step details is written for the customer as the reader. You can even include checklist items for the customer to complete. For example:

Let's have a quick look at how these steps have been scheduled.

While it's relatively straightforward - you're not using group conditions or step conditions - in the "Onboarding sessions" group, the step are organised according to dependencies.

Each onboarding call has 2 dependent steps: a customer to-do (homework) following on from that session, and the next onboarding call.

In each case, the customer to-do has been scheduled for the day after the call, and the next call has been scheduled for a week after the previous call.

Step dependencies can also be combined with conditions; we show an example of this in the Sequence below.

Although group conditions and step conditions haven't been used here, you could easily set up Workflow entry criteria so that the Workflow Template is automatically applied to specific Companies (e.g. new SMB Companies).

Sequences are great for automatically sending emails, although they can also include task steps. Sequences are useful for many different scenarios, such as End User re-engagement campaigns or responding to different NPS submissions, and can even be designed for the Company model, responding to Company events (e.g. a phase change or an upcoming renewal) and emailing multiple End Users at that Company at a time.

However, in this article we will focus on a very common type of Sequence: an End User Sequence that follows a pathway or funnel - you may hear this referred to as "Sequence milestones". In this case, there are dynamic groups that each End User passes between.

(The bottom groups here are collapsed - you'd just click the chevron (arrow) icon to the left of each group name to expand them out and show the steps contained within.)

Groups, and therefore group conditions, are really useful for lots of different scenarios. In some Workflows, only some groups are activated for each customer, and those groups stay activated - for example, you could have a group per End User language. For more examples about group conditions, check out our separate article here.

In this particular example, each End User moves through each group in turn.

To learn more about how to set up group conditions, see here.

Let's take a closer look at this bottom step here. It has a condition applied to the step itself (as shown by the orange icon). It is also a dependent step (shown by the fact that it's indented), so it counts as "Multi-factored timing" (stated in grey on the right-hand side).

Firstly, let's look at the step condition itself. In this case, it's looking at a particular characteristic/category on the End User, rather than changing usage data. This step is an additional email to be sent if the End User is classed as Tech/Ops.

If we assume each specific End User will either always be Tech/Ops or never be Tech/Ops, this makes the timing quite simple. The condition will be met right away and then the email step timing will count from the parent step like a regular dependent step, or alternatively the condition will never be met and this email will never be sent. For a more detailed discussion of step timings when you have both step conditions and step dependencies, check out our guide here.

If you're inspired to start creating your own Workflows, take a look at our guides below: