How Flows Work

📅 Published on

📝 Last updated

We’re currently revamping our documentation for 4.0.
See old documentation →

Documentation

»

Flows

»

How Flows Work

Overview

Flows are the primary automation feature in Groundhogg. They allow you to create automated customer journeys and experiences that will help you foster better relationships and engagement. Flows are incredibly powerful and can be the difference between moderate success and really killing it!

This page outlines…

  • How triggers, actions, and logic work together to create flows
  • Special use cases of triggers and logic
  • How contacts progress in flows through the different step types.

Looking instead for specifics on how to use the flow editor?

What are flows for?

You want to use a flow whenever you need to automate a task and then track the outcome. An example flow might look like…

  1. A subscriber submits a form with their email address
  2. You send an email with a coupon code to the subscriber
  3. You send follow-up emails until they use the code.

There are unlimited possibilities for flows, when used properly that can help you amplify your message with your subscribers.

Understanding Steps

Flows are made up of steps (or nodes), of which three types exist.

  • Triggers
  • Actions
  • Logic

You combine these steps together to create a flow.

Triggers

Triggers are responsible for…

  • Adding contacts to flows,
  • Moving them through the stages of a flow,
  • and Removing them from flows.

Triggers are triggered whenever the contact does something on your website or interacts with you in some way. Like submitting a form or clicking a tracking link.

Actions

Actions are how we respond to a contact’s interaction with us. For example, we might want to send them an email or apply a tag to their contact record when they visit a page.

Actions are performed as they are reached by the contact in the flow.

The exception to this are timers, which hold the contact at the timer position until the desired wait period is reached.

Logic

Logic steps provide you the ability to direct the contact through a different series of actions depending on their attributes. For example, you could send a contact down two different branches with different sets of emails based on whether they the customer tag.

Starting a flow

Contacts will enter a flow automatically whenever the conditions of an entry trigger are met. Such as when a tag is applied to their record.

You can use multiple triggers to start a flow as well! You can start a flow when a form is submitted or when a tag is applied.

Contacts can enter a flow from an inner trigger if it’s designated as an entry trigger. You can do this in the trigger settings in the editor. Triggers designated as entry points will have a door icon, as pictured.

Progressing in a flow

Once contacts are in the flow, they will proceed through the series of actions proceeding the trigger they entered from, in order until…

  • they reach a trigger where they haven’t yet met the conditions, at which point they wait there until they do,
  • or they meet the conditions of a proceeding trigger and subsequently proceed down the next series of actions,
  • or the funnel ends.

Triggers, when used “in” a flow, meaning the trigger is not starting the flow (so inner triggers), act as magnets that pull contacts to that point in the flow. This makes it easier to create reaction-based email sequences by reducing the amount of branching logic. You’ll be able to identify inner triggers as “Until…” will appear above them.

When a contact meets the conditions of a trigger at the end of a flow, the contact will jump to the end instantly, skipping all other actions in the flow. This is ideal to end long email sequences that you may want to stop if at any time the contact’s status changes.

Contacts will only move to triggers or start a flow from a trigger at the exact moment they meet the conditions. Triggers are not retroactive and will not apply to contacts that might already meet the conditions when the flow is activated.

For example, if you create and activate a new flow that starts when the customer tag is applied, any customers that already have the customer tag will not enter the flow. Only contacts that have the customer tag applied after the flow is activated will enter.

Trigger order & direction

Flows are directed!

Contacts move from top → bottom.

Thus, the order of your triggers in the flow is important, as contacts can’t move ↑ in a flow with triggers only ↓. Once they have moved past a trigger, even if they meet the conditions of a previous trigger, they will not move up to that point in the flow.

In this example, when the contact submits the Request Lead Magnet Form trigger, they are sent the Send Lead Magnet email action.

If they click the download link trigger, they will then get the Follow-up email action.

BUT, if the Booked Meeting tag is applied before they click the link, they will not get the email, as they can’t move up to the Download link trigger.

To summarize, contacts progress in a flow every time they meet the conditions of a trigger.

They do not have to meet the conditions of every single trigger in order, but they can move to any trigger that comes after their current position in the flow.

Once a contact moves to a trigger position, they cannot move up to a previous trigger, even if they meet the conditions.

Restarting flows

The exception to moving up in a flow is if they restart a flow by re-entering via an entry trigger. If the contact re-enters a flow via an entry trigger, they can move through the flow as if for the first time unless you’re employing logic anywhere that would alter their journey.

A common use case would be if you had an email sequence that would remind someone to log in. The contact would restart the flow every time they logged in, resetting their position in the reminder sequence.

Branching with Logic

Some of the logic steps will create branches in your funnel. You can create unique sequences within these branches depending on the attributes of the contact.

For example, if the contact has the customer tag, we’ll send them an email acknowledging their status as a customer.

Otherwise, we’ll send them a more promotional email designed for leads.

Contacts cannot move between parallel branches (branches that share the same parent logic node). Once they are in the branch, they will progress through that branch and eventually rejoin the main branch, regardless of whether their attributes change.

The branch conditions are only evaluated at the point of entering the branch, so no retroactive weirdness can occur.

Branching when Restarting a flow

If a contact restarts a flow, then when a contact reaches a branch the conditions will be re-evaluated based on the contact’s current attributes.

The exception is with the Split Test and Random Distribution logic, which both have an optional setting to force the contact to travel the branch used in their previous run for the sake of continuity.

Nested Branches (Branching within Branches)

You can nest branch logic within branch logic. Cool!

There is no limit to how deep you can go. Just don’t get lost!

Triggers within Branches

You can use triggers within a branch. Here are the possible scenarios.

If a contact is in the same branch as the trigger…

…then the trigger behavior is as it would normally be in the main branch.

If the trigger is in a branch, but the contact position is before the branch starts…

…then the branch conditions are evaluated first to see if the contact would have gone into that branch. If the contact meets the branch conditions and the trigger conditions, then they will move into that branch to the trigger position. Otherwise, they will continue in the flow normally.

It’s worth noting that this applies to nested branch logic as well. The contact would have to meet the conditions of every nested branch from their current position in the flow to the trigger.

If the trigger is in a parallel branch to the contact…

…then nothing, because contacts cannot move between parallel branches. They will continue in the flow as normal.

If the contact is in a branch, but the trigger is after the branch finishes…

…then they will move to that trigger, as contacts can always move to triggers that come after their current position within the same or parent branch.

Flows with the Conditional Logic Add-on

If you’re using the conditional logic add-on, you will have additional options to control which triggers and actions a contact can move through.

See our document for the conditional logic add-on.

Was this helpful?

Let us know if this document answered your question. That’s the only way we can improve.