Goals and exits

Most flows exist to get the contact to do something: finish the purchase they left in the cart, book an appointment, leave a review. Two settings turn that purpose into the flow's own configuration. Exit events take a contact out of the flow the moment they do something that makes the remaining messages pointless — nobody should get a cart reminder after paying. The goal tells Instasent what success means for this flow, so the panel can show how many runs achieved it.

The two work together. An exit event can also be the goal: the purchase both stops the reminders and counts as the success. And when success isn't an event but a point in the flow — the message was delivered, the contact clicked — a Goal reached step marks it there. Exit events aren't the only way a run ends early, and the last section gathers the others. The section to read carefully is When a goal counts: a goal only counts once the flow has sent the contact a message, and that one rule answers most questions about goal figures.

Exit events

An exit event is an event that ends the contact's run as soon as they do it: they leave the flow and get nothing more from it. Exit events aren't steps you place on the canvas; they guard the whole flow, whatever step or branch the contact is on and however long they have been waiting. Typical examples are Order created in an abandoned-cart or browse-abandonment flow, Form submitted in a flow that invites the contact to fill in a form, or Customer unsubscribed in a flow you want to stop for anyone who opts out.

Add an exit event

1. 1

   Open the Goal & exit tab

   In the Build tab, click the trigger card at the top of the canvas and open the Goal & exit tab. The card's third row opens it directly: while nothing is set it reads Goal or exit ("Set what counts as success, or when to let people out").

2. 2

   Add the event

   Under Exit events, click Add exit event. Pick the Data source (it starts on Any data source) and then the event in Choose an event.

3. 3

   Narrow it down, if needed

   With Add event condition you can require values in the event's data, for example an order above a certain amount. Like the trigger's conditions, they all have to be met.

4. 4

   Decide whether it means success

   Check Use this event as the flow's goal if the event is the result the flow is after; see Mark success: the goal.

5. 5

   Save and publish

   Click Save changes. Like every other change in the draft, the exit events apply to contacts who enter after you publish; contacts already inside keep the version they entered with (Testing, publishing and versions).

A flow can have up to 10 exit events, and the contact leaves on whichever happens first. While the tab is empty it says so: "No exit events. Contacts only leave when they finish the flow. Add an exit event to let them out earlier, and tick it as the goal if it means success." Each exit event appears as a card titled with its event (or Exit 1, Exit 2… until you pick one), with a bin icon to remove it. The cards are grouped under Goal when (the ones marked as goal) and Exit when (the rest), and the trigger card on the canvas shows the same two rows, so you can see a flow's way out without opening anything.

An exit event can stay on Any data source: it then ends the run whichever source sends the event. Choose a specific source only when the same event can come from more than one source and just one of them should count. Exit events react to the same events that can start a flow, so the events listed as unable to start one (Which events can start a flow) can't end a run either, and neither can the events that never start a flow because of their date or origin (Limits and safeguards).

Having any exit event makes the Instant processing mode unavailable for the flow; see processing mode.

What happens when the contact does it

When a contact inside the flow does one of its exit events, the run ends within seconds, wherever the contact is. A wait of three days is cut short, and no further message is sent after the exit. A message that was already queued at that very moment is still sent.

Only events that happen after the run started end it. An event from before the run belongs to the entry check described next.

In the flow's Activity, a run ended by an exit event shows the status Canceled, and its contact journey says "The contact left through one of the flow's exits." When the exit event is also the goal, the status reads Goal met or Goal without a send instead, depending on whether the flow had already written to the contact (see When a goal counts). How to read each run is explained in Monitoring a flow.

Messages sent before the exit are billed like any other message; the ones the exit prevented are never sent, so they cost nothing.

Exit events are also checked at entry

The flow also looks for exit events at the moment the contact is about to enter. A contact who has done one of them shortly before the event that triggers the run, or between that event and the moment of entry, doesn't enter at all. The typical case is a customer who starts a checkout and pays a few seconds later, while the entry is still waiting out its short processing window (processing mode). That contact appears under Didn't enter with the reason "The exit event arrived before the contact entered". It is the expected behaviour, not an error: the flow kept a reminder away from someone who had already bought.

This check looks only around the event that triggers this run, not at the contact's whole history. A customer who ordered last week and starts a new checkout today enters normally. To keep recent buyers out of a flow, use the trigger's audience instead, for example with Exclude segments and a segment of contacts who bought in the last few days (Who can enter: the audience).

The trigger event never ends its own run

The event that started a run never ends that same run, even when the trigger event and an exit event are the same type. The next occurrence of that event does: it ends the current run and, if the re-entry limits allow it (How often a contact can enter), starts a new one.

That makes a useful pattern for anything that counts from the last time something happened. The Win back customers template works this way (Flow templates): it starts on Order created, waits 30 days (plus a Smart delay to pick the moment) and then sends a message, and has Order created as an exit event used as the goal. A customer who orders again during those 30 days leaves the current run, and the new order starts a fresh one, so the 30 days always count from the latest order. The message is the last step, so a customer who orders after receiving it has already finished the run: that order starts a new run, and it counts as the finished run's goal if your attribution credits it to the message (A goal after the run has ended).

Example: an abandoned cart that stops when the customer buys

An Abandoned cart flow starts on Checkout started and has Order created as an exit event, used as the goal. Its steps: a Smart delay of between 5 minutes and 8 hours, an SMS with a link to the cart, a Wait for activity of 1 day that waits for a tap on that link, and, for those who don't tap it (No interaction), a Fixed delay of 1 day and a second SMS with a 10 % coupon. This is how it treats each customer:

When the customer buys	What happens	Status in Activity
Seconds after starting the checkout, before entering	They don't enter the flow.	Listed under Didn't enter: "The exit event arrived before the contact entered"
During the Smart delay, before any message	They leave without receiving anything.	Goal without a send
After the first SMS (during the Wait for activity or the Fixed delay)	They leave and don't get the coupon.	Goal met
They don't buy or tap the link	They get both messages and reach the end of the flow.	Completed

If a customer bought and still received a reminder

Mark success: the goal

A flow's goal is the result it is meant to produce: a purchase, a booking, a click, a reply. Declaring it lets the panel measure the flow by that result: how many runs met the goal, and the goal rate, which is the share of runs that met it among those the flow wrote to. A flow without a goal still works; it simply has no success figure, and its figures show No goal set where the rate would go (Flow analytics).

There are two ways to declare a goal. Both mark the run as a success, and both follow the same counting rule (next section).

Use an exit event as the goal

Check Use this event as the flow's goal on an exit event: "When this event fires, the run ends as a success and counts towards the goal rate." The contact leaves the flow, as with any exit event, and the run counts as a success. This is the usual choice when the success is also the moment the flow should stop, such as the purchase in an abandoned-cart flow.

Any event can be a goal, and several exit events can be goals at the same time (any of them counts). Check the box only on events that mean success. Exit events that are just housekeeping, such as Customer unsubscribed, should end the run without counting as a success, so leave them unchecked.

Place a Goal reached step

The Goal reached step, in its own Goal group of the step palette, records the goal at the point where the contact reaches it: "Record that the contact met the flow's goal, and carry on". It doesn't send anything, it doesn't branch and it doesn't end the flow: the contact moves on to the next step, which is what the card says ("Records the goal, and carries on"). There is nothing to configure; its panel says "This step needs no setup." It can sit on the main path or inside a branch, where it records the goal only for the contacts who go through that branch. It can be duplicated but not copied (Building a flow).

Use the step when success is a place in the flow rather than an event — the branch of a Wait for delivery that receives delivered messages, the branch of a Wait for activity that receives the click or the reply — or when the contact should stay in the flow after succeeding, for example to receive a thank-you:

• Send a reminder, then a Wait for activity with a Did an event branch on Order created, with your store as its data source.
• In that branch, a thank-you message followed by Goal reached.
• In No interaction, a second reminder.

In a flow like this, don't also add Order created as an exit event: the exit can end the run before the branch's thank-you is sent. Use the purchase in one place or the other, depending on whether buyers should hear from this flow again (Waits).

The two ways can be combined in the same flow; even so, a run counts at most one goal.

When a goal counts

The reason is what the goal measures: what the flow achieved among the people it wrote to. A customer who bought before the flow sent them anything would have bought anyway, so the flow takes no credit for it. In short, a message sent before the goal is the only condition, and it is checked in the run itself:

flowchart TD
    G["The run reaches its goal: a goal exit event or a Goal reached step"] --> Q{"Has this run already sent the contact a message?"}
    Q -->|Yes| OK["The goal counts. Status: Goal met"]
    Q -->|"No, and it was a goal exit event"| NS["The contact leaves without a goal. Status: Goal without a send"]
    Q -->|"No, and it was a Goal reached step"| NR["Nothing is recorded. The contact carries on"]
    class OK success

The "before any message" goals are a separate group from the goals that count: Goal is the goals met after the contact received something from the flow, and "before any message" the goals met before it. The two never overlap, and the percentage the report shows for "before any message" is over all the goals met (6 of 9 is 67 %). The goal rate leaves them out (Flow analytics).

Goal without a send

When a goal-marked exit event arrives before the flow has sent anything, the contact still leaves the flow, but the run doesn't count as a goal. Activity shows it as Goal without a send, and the flow report lists those runs apart, as goals reached "before any message" (Flow analytics). They don't enter the goal rate.

This is correct behaviour, and in flows that start with a wait it is often a large share of the runs: in an abandoned-cart flow, everyone who buys during the first wait lands here. It is the flow doing its job, keeping a reminder away from people who had already bought.

A Goal reached step before any message

A Goal reached step that a contact reaches before the flow has sent them anything records nothing: no goal, and no "goal without a send" either. The contact simply carries on, and a later goal (another Goal reached step after a message, or a goal exit event) can still count.

The editor warns about this placement. When a Goal reached step can be reached without any message before it, the toolbar shows a notice such as "1 goal step with no message before it", with the explanation: "A goal only counts once we have sent that person at least one message. A goal step reachable without sending anything never records. Move it after a message, or add one before it." The notice doesn't stop you publishing; it tells you the step will never count where it is.

One goal per run

A run counts at most one goal. The first goal that counts wins; a later goal event or another Goal reached step in the same run adds nothing. A contact who enters the flow again starts a new run, which can count its own goal. Once a run has recorded its goal, Activity shows it as Goal met, even if the contact goes on through later steps.

That is why the goal rate never goes above 100 %. Its definition and the other figures are in Flow analytics.

A goal after the run has ended

A goal can also arrive after the run is over, for example a purchase two hours after the contact reached the end of the flow. If the goal exit event is a sale that your attribution settings credit to one of this flow's messages, it still counts as that run's goal. The period in which a sale can be credited is set by your project's attribution windows (Conversions & attribution).

Goals and revenue are separate numbers

A goal carries no money. A flow's revenue, conversions and ROAS come only from attribution, exactly as for campaigns: a sale is credited to the flow when it follows one of its messages within your attribution windows (Flow analytics). So the two figures can legitimately differ: a run can meet its goal with no sale attributed to the flow, and a sale can be attributed to a flow whose goal is something else, or that has no goal at all.

Count a goal only on delivery or on a click

Because the rule asks only for a message sent, a goal can count for a contact whose message was never delivered. If your success needs more than that, build it into the flow with a Goal reached step:

• Delivered: Send message → Wait for delivery → Goal reached in the Delivered branch (Wait for delivery).
• Clicked: Send message → Wait for activity → Goal reached in the Any link click branch, or in a Tapped a specific element branch for one link in particular (Wait for activity).

Keep the goal in one place in a flow like this. If a goal exit event is also set, it can record the goal first, and as a run counts only one goal, the stricter step would add nothing.

Test runs record the goal on the contact journey, so you can check where it would count, but they never count in the flow's figures (Testing, publishing and versions).

Other ways a run ends

Besides exit events, a run can end in these ways:

• It reaches the end. The flow's main path ends in the Flow completed marker, and branches rejoin that path below their split. A contact who gets there finishes the run, with the status Completed (or Goal met if the run recorded its goal along the way).
• It reaches an Exit flow step. Exit flow, in the End the flow group of the palette, "Ends the flow for the contact." It only exists inside a branch, and nothing can follow it in that branch. Normally, a contact who finishes a branch continues with the steps below the split; a contact who reaches Exit flow doesn't, and their run ends as Completed there. Use it when one branch should skip the rest of the flow, for example the No consent branch of a Check consent step (Branches).
• The contact leaves the audience, with the option on. The trigger's audience is checked only at entry. In the Goal & exit tab, the switch Cancel the run if the contact leaves the audience (off by default) changes that: "A contact can stop matching the audience after entering. This rechecks it at every step and removes anyone who no longer matches, exclusions included." The check happens just before each step, so a contact who leaves the audience during a long wait is taken out when the wait ends, before the next step. The run shows Canceled, and the journey says "The contact left the required audience or segment." The option doesn't apply to test runs. Turn it on when the flow only makes sense while the contact belongs to the audience, such as a flow for VIP customers.
• A message can't be sent. With Stop the run if the message can't be sent on, which is the default, the run stops at that step with the status Stopped (When a message can't be sent).
• Someone cancels it. Cancel executions on a version, or Cancel execution on one contact's journey, ends the runs on the spot: status Canceled, and the journey says "The run was ended manually." (Managing flows).

Pause enrollment doesn't end any run, and neither does Disable in the flows list, which is the same action: nobody new enters, and the contacts already inside finish their journey (Managing flows).

How the run ended	Status in Activity	What the contact journey says
It reached the end, or an Exit flow step	Completed	—
An exit event	Canceled	"The contact left through one of the flow's exits."
A goal exit event, after a message	Goal met	"The contact left through one of the flow's exits."
A goal exit event, before any message	Goal without a send	"The contact left through one of the flow's exits."
The contact left the audience (option on)	Canceled	"The contact left the required audience or segment."
A message couldn't be sent (stop option on)	Stopped	"The step could not send the message.", followed by the reason
Cancelled by hand	Canceled	"The run was ended manually."

A run that recorded its goal shows Goal met however it ends. The complete list of statuses and reasons is in Monitoring a flow.

Related