# Exit rules

Exit rules define when a contact should leave the Journey early.

Exit rules are configured from the **Exit rules** control in the builder toolbar. They apply to the **whole Journey**, not to a single step or branch.

<figure><img src="/files/eiNwcEShBzCEeRV6qlfz" alt="Exit rules panel in the Journey builder showing no rules configured and a locked state indicator"><figcaption><p>The Exit rules panel — exit rules apply across the entire Journey and are locked while the Journey is Active.</p></figcaption></figure>

## What exit rules do

When an exit rule condition becomes true for a contact, that contact is removed from the Journey immediately — regardless of which step they are currently at.

Use exit rules when there is a business event or customer state that should stop the flow as soon as it happens.

**Common examples:**

| Scenario                                                      | Exit rule                               |
| ------------------------------------------------------------- | --------------------------------------- |
| Stop sending once a customer converts                         | Profile field: `status = converted`     |
| Stop a re-engagement flow when a customer reactivates         | Profile field: `is_active = true`       |
| Stop a churn-prevention flow when a cancellation event occurs | Event table: cancellation event         |
| Stop a trial flow once a contact upgrades                     | Event table: subscription upgrade event |

## Available exit rule types

### Profile fields

Use this when the contact should exit because a profile attribute matches a condition.

**Example:** exit if `plan_status = cancelled` or `lifecycle_stage = churned`.

The condition is evaluated against the contact's current profile at the time of each Journey run.

### Event table

Use this when the contact should exit because an event happened.

**Configuration:**

| Field                | Description                                                   |
| -------------------- | ------------------------------------------------------------- |
| Event table          | The event model to check                                      |
| Occurrence threshold | Optional — exit only after the event happens at least N times |
| Event conditions     | Optional — filter by event properties                         |

## Operator behavior

If multiple exit rules are configured:

* **OR** — any matching rule removes the contact (recommended for most cases)
* **AND** — all configured rules must match simultaneously before the contact exits

{% hint style="info" %}
OR is the right default for most exit rules. Use AND only when the exit condition is truly a combination — for example, "exit only if the customer both converted AND is in a specific region."
{% endhint %}

## Limits and operating rules

| Rule                           | Value                               |
| ------------------------------ | ----------------------------------- |
| Maximum exit rules per Journey | 10                                  |
| Can edit while Active          | No — locked while Journey is Active |
| Minimum required               | None — exit rules are optional      |

{% hint style="warning" %}
Exit rules are locked while the Journey is Active. If you need to add or change an exit rule, pause the Journey first, make the change, then re-publish.
{% endhint %}

## When to add exit rules

Add exit rules when:

* The Journey represents a flow toward a business outcome (conversion, activation, upgrade)
* A later event should immediately stop further activations regardless of step position
* You want to avoid contacting a customer who has already taken the desired action

Exit rules are **especially important** for:

* Conversion flows — stop sending once the goal is reached
* Churn-prevention flows — stop once the customer is no longer at risk
* Subscription or billing flows — stop once the payment or upgrade event occurs

## Best practices

* Write exit conditions in business terms, not technical noise. `status = converted` is more readable than a raw timestamp condition.
* Keep the rule readable enough that a non-technical operator can explain it in a sentence.
* If a Journey should never continue after conversion, always make that explicit with an exit rule rather than relying on the flow to end naturally.

## Related pages

* [Entry rules](/journey/concepts/entry-rules.md)
* [Designing safe Journeys](/journey/best-practices/designing-safe-journeys.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dinmo.io/journey/concepts/exit-rules.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
