Skip to main content

Exit criteria in Automations

Use exit criteria in Custom Automations to define when a run should stop - e.g. in response to an email reply

Written by Ziqi Guo

Summary

  • "Exit criteria" is an optional setting you can configure on the trigger of a Custom Automation

  • Exit criteria define the circumstances in which an Automation run should stop before it has finished - so the Automation is abandoned part-way through, rather than continuing to completion

  • This is especially valuable for long-running Automations, such as multi-step email sequences that span days or weeks, where the reason for running the Automation may disappear before the last step is reached

  • Exit criteria are built in a flexible way: choose the built-in "Email replied" event, or select "Custom" to watch any data model with your own conditions

  • Exit criteria are the counterpart to your trigger and trigger filtration: the trigger defines when a run starts, and the exit criteria define when it stops

Who is this article for?

  • Planhat Users who are building Custom Automations for their organization (e.g. Tech/Ops)

Series

This article is part of a series on Automations:

Article contents

This is a technical deep-dive article

Read on if you'd like to learn about exit criteria - an optional setting on the trigger of a Custom Automation. Ensure you read our article on Custom Automations before this one, so you are familiar with the context of where Automation exit criteria can be used.

If you would simply like a general introduction to Automations, check out our overview article here.

Introduction

Automations work on the basic principle of "when x happens, do y". The "when x happens" part is the trigger, and you can narrow it down further with trigger filtration, so that only the runs you care about ever start.

That works perfectly when an Automation completes in a moment. Many of the most valuable Automations do not, however: an email cadence might send the first email today, wait a week, check whether it was opened, and send a follow-up after that. Over a window that long, the situation that justified the Automation in the first place can change. The Company may move on to a different Phase. The Objective you were chasing may be completed. The risk you were mitigating may be resolved. Continuing to send emails at that point is, at best, noise - and at worst, it undermines the customer relationship.

Automation exit criteria solve this. They let you define the circumstances in which an in-flight Automation run should stop, so a run that is no longer relevant is abandoned rather than played out to the end.

If you have previously built legacy Sequence Workflow Templates with exit criteria, this will feel familiar: Automation exit criteria bring the same entry/exit thinking to Custom Automations - with considerably more flexibility about what you can look at.

📚 Further reading

  • For an overview of Automations in general, including benefits and use cases, check out our introductory article here

  • To learn about how to create Custom Automations - where you configure exit criteria - see our separate article here

  • Exit criteria are frequently used alongside "Wait" steps and "Wait Until" steps, which are what make an Automation run long enough for exit criteria to matter

What are exit criteria in Automations?

📌 Important to note

In this article, we are specifically covering exit criteria in Automations. For information on exit criteria in Workflow Templates (Projects and Sequences) built in the "Workflows" Global Tool, please refer to our separate article here.

Exit criteria are configured on the trigger of a Custom Automation, rather than being a step in their own right. When you click on the trigger box in the flow chart, its configuration panel opens on the right-hand side with two tabs: "Trigger" and "Exit Criteria". A green dot on the "Exit Criteria" tab tells you, at a glance, that exit criteria have been configured.

Click the image to view it enlarged

There are two ways to define the exit criteria, chosen from the dropdown menu in the top-right corner of the tab:

  • "Email replied". The run stops as soon as the customer replies to an email the Automation sent. You choose which emails count, by selecting the relevant "Schedule Email" step(s) of the Automation

  • "Custom". For anything else, select "Custom" and describe the event yourself: the model to watch (e.g. Company, Objective, Workflow, Asset), the type of event (e.g. "updated"), the record to watch, and the condition(s) that should end the run. The record can be the one in the trigger, or another record whose ID is held on the trigger record

While an Automation run is in progress, Planhat evaluates the exit criteria against the events coming in. If a matching event meets the conditions, the run stops at whatever point it has reached, and no further steps are executed.

📌 Important to note

Exit criteria apply to runs that are already in progress. They stop a run that has started; they do not prevent runs from starting. To control which runs start in the first place, use your trigger and trigger filtration.

Why use exit criteria in Automations?

The short answer: because the world moves on, and an Automation that keeps running after its reason has disappeared costs you credibility with your customers.

Some typical use cases are:

  • The customer replies. The most common exit criterion of all for an outreach sequence: the moment the End User replies to one of the emails, stop the sequence and let the conversation continue with a person

  • Onboarding engagement sequences. You start a multi-email nurture sequence when a Company enters the Onboarding Phase. When the Company completes onboarding and moves into another Phase, the remaining emails are no longer appropriate - so you exit

  • Objective and outcome chasing. You start a sequence to drive a particular Objective forward. As soon as that Objective is completed (e.g. its confidence reaches 100), there is nothing left to chase - so you exit

  • Risk and churn mitigation. You kick off an escalation flow when a risk signal appears. When the underlying signal clears, or a CSM takes over manually, the automated flow should get out of the way

  • Renewal outreach. You start a renewal sequence ahead of a renewal date. Once the renewal is closed-won, the remaining reminders would be, at best, confusing

  • Avoiding duplicate outreach. You exit an automated sequence as soon as a human on your team engages the customer directly, so the customer is never worked by a person and an Automated sequence at the same time

📌 Important to note

In this article, we are using the word "sequence" in the generic sense, in terms of an email cadence.

You can create a Custom Automation to automatically send emails, which is what we are focusing on here.

Note that by enabling "Workflow Mode" ("Create Sequence") in an Automation, it effectively becomes a kind of Sequence Template, where a Workflow record will be created when the Automation is run. We describe this in a separate article, coming soon.

Be aware that this is a different type of Sequence Template than that created using the legacy method via the "Workflows" Global Tool (described here), so the two should not be confused.

How to set up exit criteria in Automations

When you are configuring (creating or editing) a Custom Automation in the App Center, click on the trigger box at the top of the flow chart to open its configuration panel.

  1. Set up your trigger as normal - select the model and event that should start the Automation, and add any trigger filtration you need. See our Custom Automations article for full details of this

  2. Open the "Exit Criteria" tab of the same configuration panel, and choose the type of exit criterion from the dropdown menu in the top-right corner: "Email replied" or "Custom"

  3. Define what should end the run

    1. "Email replied". In the "Stop on reply to" field, select the "Schedule Email" step(s) you want to watch. The dropdown lists the "Schedule Email" steps in this Automation by name, and you can select more than one - so a reply to any of those emails ends the run. There is nothing else to configure

      • 🚀 Tip: Because the emails are listed by step name, renaming your "Schedule Email" steps to something meaningful (e.g. "email-1" or "welcome email") makes this list much easier to read

    2. "Custom". Select the Model you want to watch and the Event - "updated", "deleted", "added to filter" or "removed from filter". Then, in the ID field, specify the record to watch, using a replacement code (dynamic reference). Underneath, build the Conditions that should end the run: click "+ Rule" to add a row, choose the property/field, the operator and the value

      • 🚀 Tips

        • To learn all about Automation replacement codes, check out our separate article here

        • Type << in the box to display all your available options; keep typing (e.g. <<object) to filter the list

        • object refers to the record in the Automation trigger, so <<object._id>> watches the record that started the run - which is also what happens if you leave the "ID" field empty

        • To watch a different record, use a field on the trigger record that holds its ID - e.g. <<object.companyId>> or paste in a specific Planhat ID

        • The "ID" field has to resolve at the moment the run starts, so it cannot reference a record that a later step will fetch or create (see the note in the gray box below)

        • Like when building filters elsewhere in Planhat, you can choose between "match all" and "match any", and you can use groups of rules ("+ Group"). Check out the article linked above for further details of how to set these up

  4. Save your Automation

📌 Important to note - the "ID" field must resolve when the run starts

Exit criteria are armed at the moment the Automation is triggered, before any step has run. Whatever you put in the "ID" field therefore has to be resolvable at that point:

  • ✅ <<object._id>>, or a field on the trigger record that holds another record's ID (e.g. <<object.companyId>>)

  • ✅ A specific Planhat ID, pasted in

  • ✅ Empty - the exit criteria will then watch the trigger record itself

  • ❌ A reference to a later step, such as <<Step 1._id>> for a record fetched by a "Get" step. That record does not exist yet when the exit criteria are armed, so you can't use this in your Automation exit criteria

Worked example of an Automation with exit criteria

Let's bring this together with an example: a scaled CS engagement process that runs while a Company is being onboarded.

Trigger - "Company updated"

The Automation is triggered when a Company is updated, with trigger filtration set so that it only starts when the Company's Phase is equal to "Onboarding". In other words, when a Company enters onboarding, we begin engaging them.

Click the image to view it enlarged

Exit criteria - the Company leaves onboarding

The Automation sequence itself runs over several weeks, with "Wait" and "Wait Until" steps between the emails. If the Company finishes onboarding half-way through, we don't want to keep sending onboarding content. On the trigger, therefore, we configure exit criteria:

  • Event: "Company updated"

  • ID: <<object._id>> - the Company that triggered this run

  • Condition: Phase is not equal to "Onboarding"

Click the image to view it enlarged

Now, as soon as that specific Company moves out of the Onboarding Phase, the run stops and the remaining emails are never sent.

Variation - exiting when the customer replies

For an outreach sequence, the exit criterion you will reach for most often is simply "they answered". To set this up, in "Exit Criteria", select "Email replied", and pick the "Schedule Email" step(s) that sent the emails, and then the run will stop as soon as the End User replies - so nobody receives an automated follow-up after they have already responded.

Click the image to view it enlarged

📌 Important to note

What you cannot do is watch a record that a later step fetches or creates - for example, using a "Get" step to retrieve an Objective and then referencing <<Step 1._id>> in the exit criteria. Exit criteria are armed before the first step runs, so that reference is empty and the Automation will never exit. See the note in the gray box in the previous section of this article.

More tips and things to note

  • Design your exit criteria at the same time as your trigger. The question "what would make this stop being a good idea?" is worth asking before you build the steps, not after your first run has gone out

  • Keep exit conditions simple where you can. A single, unambiguous condition ("Phase is not Onboarding") is easier to reason about - and to troubleshoot - than a large set of overlapping rules

  • If a run never exits, check the "ID" field first. An exit criterion pointing at a record that could not be resolved when the run started produces no error - the run simply continues to the end

  • Test with a short Automation first. Because exit criteria only apply to in-flight runs, the quickest way to test them is with a shortened version of your Automation (e.g. a "Wait" step of a few minutes), so you can trigger a run, change the record, and confirm the run stops as expected

  • Check the Automation run logs if a run stops when you didn't expect it to, or keeps going when you expected it to stop. See our separate article on Automation logs and troubleshooting

Did this answer your question?