# Goals and exits

How to define what success means for a flow, when a goal counts, and the ways a contact leaves a flow before the end.

**Language:** en
**Audience:** platform
**TLDR:** Exit events, set in the trigger's Goal & exit tab (up to 10), end a contact's run within seconds wherever they are, and keep out contacts who did one just before entering. Mark an exit event as the flow's goal or place a Goal reached step: a goal counts only if the run had already sent the contact at least one message, with no click or delivery needed. Goals carry no money; revenue comes from attribution.
**Translation key:** platform.automations.flows.goals-and-exits
**Search keywords:** conversion goal, success metric, stop flow when purchase, stop reminders after purchase, bought and still got the reminder, exit condition, cancel when, goal step, goal met, goal rate, counted without a click, end flow, exit flow step, flow completed, leave audience, leave segment
**Related pages:** /platform/es/automations/flows/goals-and-exits, /platform/en/automations/flows, /platform/en/automations/flows/triggers-and-entry, /platform/en/automations/flows/waits, /platform/en/automations/flows/flow-analytics, /platform/en/automations/flows/monitoring-a-flow, /platform/en/project-settings/conversions-attribution
**Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt
**This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/llms.txt
**This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/goals-and-exits/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/goals-and-exits.md (Markdown)
**Other language (es):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/goals-and-exits.md

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](#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. 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. 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. 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. 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](#mark-success-the-goal).

#### 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](/platform/en/automations/flows/versions-and-publishing#contacts-already-inside-keep-their-version)).

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.

![The Goal & exit tab with an order-created exit event used as the flow's goal](/platform/en/automations/flows/images/goals-and-exits--1-goal-exit-tab.png)
*An exit event can also count as the flow's goal.*

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](/platform/en/automations/flows/triggers-and-entry#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](/platform/en/automations/flows/limits-and-safeguards#events-that-never-start-a-flow)).

Having any exit event makes the **Instant** processing mode unavailable for the flow; see
[processing mode](/platform/en/automations/flows/triggers-and-entry#when-the-contact-enters-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](#when-a-goal-counts)). How to read each run is explained in
[Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow#activity-who-entered).

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](/platform/en/automations/flows/triggers-and-entry#when-the-contact-enters-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](/platform/en/automations/flows/triggers-and-entry#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](/platform/en/automations/flows/triggers-and-entry#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](/platform/en/automations/flows/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](#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

#### A customer bought and still got the reminder

Work through these checks in order:

1. **Check the run in Activity.** Open the flow's **Activity**, find the contact and
   open **View detail**. If the journey says "The contact left through one of the
   flow's exits.", the exit worked: compare the time of the SMS (**View message**)
   with the time of the order. A message already sent, or on its way when the order
   arrived, can't be called back. If the run is **Completed**, or still **Running**,
   no exit event reached it.
2. **Check the version the contact is on.** The **Version** column shows it. Exit
   events apply only to contacts who entered after the version that added them was
   published; contacts who entered earlier finish on their old version
   ([Contacts already inside keep their version](/platform/en/automations/flows/versions-and-publishing#contacts-already-inside-keep-their-version)).
3. **Check the exit event itself.** If its **Data source** is a specific source and
   the order arrives from another one, or as a copy relayed by another tool, the exit
   never fires: use **Any data source**, or the source that really sends the order.
   Check also the event type (**Order created** is not **Order paid**) and any event
   condition, such as a minimum amount.
4. **Check that the order is on the same contact.** A purchase made with a different
   phone or email, for example a guest checkout, belongs to another contact and doesn't
   end this contact's run.
5. **Check how the order arrived.** Orders with an old date, the first sync of a new
   source and CSV imports don't end runs, just as they don't start them
   ([Events that never start a flow](/platform/en/automations/flows/limits-and-safeguards#events-that-never-start-a-flow)).
6. **Check for another flow.** A purchase stops only the flows that have it as an exit
   event. If a second flow sent its own reminder, it needs its own exit event
   ([What Flows doesn't limit](/platform/en/automations/flows/limits-and-safeguards#what-flows-doesnt-limit)).

## 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](/platform/en/automations/flows/flow-analytics#goal-rate)).

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](/platform/en/automations/flows/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](/platform/en/automations/flows/waits)).

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

## When a goal counts

> **Note**: A goal counts only if the run had **already sent the contact at least one message** when
> the goal happened. The message only has to have gone out: **no delivery confirmation and
> no click are needed**.

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:

```mermaid
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](/platform/en/automations/flows/flow-analytics#goal-rate)).

### 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](/platform/en/automations/flows/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](/platform/en/automations/flows/flow-analytics#goal-rate).

### 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](/platform/en/project-settings/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](/platform/en/automations/flows/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](/platform/en/automations/flows/waits#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](/platform/en/automations/flows/waits#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](/platform/en/automations/flows/versions-and-publishing#test-with-one-contact)).

## 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](/platform/en/automations/flows/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](/platform/en/automations/flows/sending-messages#when-a-message-cant-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](/platform/en/automations/flows/managing-flows#cancel-executions)).

**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](/platform/en/automations/flows/managing-flows#pause-enrollment)).

| 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](/platform/en/automations/flows/monitoring-a-flow#why-a-run-ended).

## Related

- [The trigger: who enters and when](/platform/en/automations/flows/triggers-and-entry) - The trigger event, the audience, re-entry limits and the processing mode.
- [Flow analytics](/platform/en/automations/flows/flow-analytics) - Goal rate, conversions, revenue and the flow report.
- [Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow) - Who entered, who didn't and why, and each contact's journey.
- [Waits](/platform/en/automations/flows/waits) - Wait for delivery and Wait for activity, to mark a goal on delivery or on a click.
- [Conversions & attribution](/platform/en/project-settings/conversions-attribution) - What counts as a sale and when it is credited to a message.

---

This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.