# The trigger: who enters and when How the event trigger decides who enters a flow and when: the event, its conditions, the audience, re-entry limits, the Enrollment pace settings and processing mode. **Language:** en **Audience:** platform **TLDR:** A flow starts from one event trigger: pick the event, optionally its data source and conditions, and who can enter (Include and Exclude segments, checked at entry). The Limits tab sets how many times and how often a contact can enter, how many runs of this flow they can have at once and how many contacts enter per hour and per day; entries over a limit are dropped, not queued. Entry waits a short processing window unless the flow uses Instant. **Translation key:** platform.automations.flows.triggers-and-entry **Search keywords:** trigger event, enrollment, enrolment, enroll, entry conditions, event filter, exclude segment, exclusion, cooldown, frequency cap, once per contact, concurrent runs, rate limit, instant, consistent, processing window, delay before entering, start flow when tag added, start flow when contact joins list, new contact trigger, welcome trigger, duplicate entry, entered twice **Related pages:** /platform/es/automations/flows/triggers-and-entry, /platform/en/automations/flows/goals-and-exits, /platform/en/automations/flows/monitoring-a-flow, /platform/en/automations/flows/limits-and-safeguards, /platform/en/audience/segments, /platform/en/data-sources **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/triggers-and-entry/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/en/automations/flows/triggers-and-entry.md (Markdown) **Other language (es):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/platform/es/automations/flows/triggers-and-entry.md Every flow begins with a single **trigger** card at the top of the canvas. It answers the two questions that decide everything that comes after: **which event puts a contact into the flow**, and **which contacts are allowed in when that event happens**. When an order is created, a checkout starts or a contact joins a list, the trigger checks the event against your settings and, if everything matches, the contact enters and starts a **run**: their own pass through the flow's steps. Each new entry is a new run, so the same contact can go through a flow more than once if you allow it. Click the trigger card to open its settings, the **Event trigger** panel ("Enrolls a contact when an event happens."). It has three tabs: **Trigger** (the event and the audience), **Limits** (how often and how fast contacts can enter, and how quickly they are processed) and **Goal & exit** (the exit events and the flow's goal, explained in [Goals and exits](/platform/en/automations/flows/goals-and-exits)). The card itself summarises the three: **Trigger when** with the event, **Limits** with the re-entry rule, and a third row for the goal or exit. Clicking a row opens its tab. Like the rest of the flow, the trigger is edited in the draft on the **Build** tab, and changes reach new entries when you publish them; see [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing). ## The event trigger A flow starts when an event happens to a contact. In the **Trigger** tab: - **Trigger type** is **Event**. The selector also shows **Schedule** with a **Coming soon** badge: it is not available yet. Once a version is published, the type is locked ("The type can't change while a version is published to Live or as a live test."). - **Trigger event** ("The event that enrolls a contact in the flow.") is where you choose what starts the flow, in two parts: - **Data source** comes first. By default it is **Any data source**: the event starts the flow whichever source sends it. Select a specific source when more than one sends the same event, for example your shop and a tool that relays its orders. A relayed copy counts as a separate event, so with **Any data source** the same order can start a run once per copy, unless your [re-entry limits](#how-often-a-contact-can-enter) stop the second one. Pointing the trigger at the source that owns the event avoids that. - Then the event itself, in **Choose the trigger event**. The list shows how many of each event your project has received recently, so you can see which ones really reach it before you build on them. - **Add event condition** narrows the event by its own data, for example only orders above a certain amount, or only checkouts from one store. Conditions combine with AND: the event must meet all of them. Filter only on values your source really sends: a condition on a field that never arrives gives a valid flow that never starts. Changing the event clears its conditions, because each event has its own data. The event's data travels with the contact through the run: messages can quote it as variables ([Sending messages](/platform/en/automations/flows/sending-messages)) and the **Check entry event** step can route on it ([Branches](/platform/en/automations/flows/branches)). If you change the trigger event later, review those steps too; the editor flags the conditions that no longer fit. Beside **Trigger event**, a small counter shows how many events of the last 7 days match the trigger; select it to jump to **Enrollment estimate**, below the audience, which shows them day by day in a chart. It counts **events, not contacts**, and ignores the audience and the re-entry limits, so it is an upper bound on activity, not a forecast of entries. If it shows nothing after a few days of normal activity, check the source and the conditions. ![The Trigger tab of an event trigger with the trigger type, the event and the audience](/platform/en/automations/flows/images/triggers-and-entry--1-trigger-tab.png) *Who can enter is checked at the moment of entry.* ### Which events can start a flow Events from your connected data sources, from the API and Instasent's own events about your contacts can start a flow. These are the events that can, grouped by kind: | Kind | Events | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Ecommerce | **Checkout started**, **Checkout updated**, **Checkout abandoned**, **Order created**, **Order paid**, **Order shipped**, **Order delivered**, **Order cancelled**, **Order refunded**, **Order chargeback**, **Product viewed**, **Product added to cart**, **Product purchased** | | Contact and consent | **Customer created / updated**, **Customer subscribed**, **Customer unsubscribed** | | Messaging and clicks | **Inbound message / Reply**, **Campaign click / call to action**, **Automation click / call to action**, **Direct message click / call to action** | | Forms and web activity | **Form viewed**, **Form submitted**, **Viewed / Visited**, **Click on link / button**, **Action performed**, **Active on site / App**, **Custom event** | | Payments and CRM | **Payment**, **Refund**, **Chargeback**, **Invoice**, **Deal added**, **Deal updated**, **Deal won**, **Deal lost**, **Meeting registered**, **Meeting canceled**, **Meeting attended**, **Meeting left**, **Subscription plan change**, **Subscription plan cancelled**, **Subscription plan renewed** | Some events can start a flow too, but the picker lists them only when your project receives them: coupon events (created, used, removed) and back-in-stock events, which some shops send, clicks on a flow's own messages, and taps on the action suggestions of an RCS message. #### Events that can't start a flow Even if you find them in the event list, these events never start a flow: **Order updated**, **Checkout cancelled**, **Customer created** on its own (use **Customer created / updated**, below), **Appointment**, **Lead / Conversion**, and the records Instasent keeps about its own messages, such as sends and opens. Separately, some events never start a flow whatever their type: events with an old date, the first sync of a newly connected source and CSV imports. That safeguard is explained in [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). > **Tip**: **Abandoned cart: trigger on the checkout, not on the abandonment.** Many shops send > **Checkout abandoned** hours after the customer stops, which is too late for a timely > reminder. Trigger on **Checkout started** instead, add a wait before the first > message, and add **Order created** as an exit event so whoever buys leaves the flow. > See [Waits](/platform/en/automations/flows/waits) and > [Goals and exits](/platform/en/automations/flows/goals-and-exits). ### Tags, lists and new contacts There is no separate "joined a list" or "gained a tag" trigger: those changes arrive as the **Customer created / updated** event, which the panel's ⓘ next to **Trigger event** calls the *update* event. Select it and add an event condition: - **Gains a tag or joins a list**: a condition on **Added tags** or **Added lists** with the tag or list you want. - **Loses a tag or leaves a list**: a condition on **Lost tags** or **Lost lists**. - **A new contact** (for a welcome series): a condition on **Is it a new contact?** set to yes. Don't use **Customer subscribed** for this: it records a subscription change, not the arrival of a new contact. The tag or list can change in any source, including a change made by another flow's **Update tags** or **Update lists** step, so one flow can start another; see [Updating the contact](/platform/en/automations/flows/contact-updates). And if two flows use the same trigger event, a contact who matches both enters both and gets both flows' messages: Flows has no cap across flows ([Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards)). ## Who can enter: the audience Under **Audience** ("Who can enter. Only contacts in this audience enter when the event fires (checked at entry).") you decide which contacts the event lets in: - **Include** takes one option: a segment, a data source, a tag or a list. The default is **All audience**, every contact in the project. Segments are dynamic, so a contact who joins the segment later can enter on their next event. - **Exclude segments** takes any number of segments: "Contacts in these segments never enter the flow, even if they match the audience above." A contact in **any** of them stays out. This option may require a higher plan; if yours doesn't include it, the panel shows **Upgrade plan**. The audience is checked **at the moment of entry**, against the contact as they are then. A contact who enters and later stops matching (leaves the segment, joins an excluded one) carries on with their run, unless you turn on **Cancel the run if the contact leaves the audience** in the **Goal & exit** tab; see [Goals and exits](/platform/en/automations/flows/goals-and-exits). A contact who doesn't match the audience when the event arrives doesn't enter and is listed under **Didn't enter** in the flow's activity ([Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow)). > **Tip**: If a segment doesn't appear when you search for it under **Include**, open the full > list of segments in the picker and select it from there. Before publishing, check > that **Include** shows your segment and hasn't stayed on **All audience**. Templates limit their audience to contacts with a mobile number, so contacts that no message could reach don't enter. Doing the same in your own flows keeps the activity and the figures clean. Filtering the audience in any way (a segment, a source, exclusions) makes the **Instant** processing mode unavailable; see [processing mode](#when-the-contact-enters-processing-mode). ## How often a contact can enter The **Limits** tab opens with **Re-entry & frequency** ("How often the same contact can enroll in this flow."). These three settings decide whether, and how often, the same contact can start a new run: - `Enrollments per contact limit` — default: `No limit` Whether a contact can enter this flow more than once: **No limit** or **Once only**. With **Once only**, a contact enters this flow a single time and never enters again: it counts entries in **all its versions**, with no time limit, including runs that were later cancelled or stopped. **Once only** hides the other two settings, because they no longer apply (their values are kept). A [test run](/platform/en/automations/flows/versions-and-publishing#test-with-one-contact) counts while its run is kept (14 days), but it leaves no permanent mark. Flows that had a custom number of entries now behave as **Once only**. - `Minimum time between enrollments` — default: `5 minutes` How long a contact who just entered must wait before entering again. Set it in seconds, minutes, hours or days, from **1 minute**; the panel shows the allowed range under the field (up to about 115 days). It is respected whatever its length, and it is how you control frequency when the limit is **No limit**. It counts from the **start** of the contact's last entry, not from when that run ended, and an attempt that was turned away doesn't restart the count. - `Simultaneous runs per contact` — default: `5` How many runs **of this flow** the same contact can have in progress at once, from 1 to 10, counting every version. It doesn't look at other flows: a contact can be inside several different flows at the same time whatever this says. The trigger card sums these up in its **Limits** row: **Can re-enter · min 5 minutes apart** (any other minimum time shows in the same way) or **Once per contact**. Common set-ups: - **Welcome series**: **Once only**, so a contact is welcomed once, even if they are updated again. - **Abandoned cart**: **No limit** with a **Minimum time between enrollments** of 1 day, so a shopper who opens several checkouts in an afternoon gets one reminder journey, not one per checkout. - **Order follow-up** (a thank-you or a review request): **No limit** with a short minimum time, so each order gets its message, while two orders from the same contact within that time produce a single run. The same event delivered twice never creates two runs, whatever the limits. **Entries over a limit are dropped, not queued.** The contact simply doesn't enter that time, and nothing is retried when the limit clears: the next qualifying event is a new attempt. Each dropped attempt is listed under **Didn't enter** with its reason ([Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow)). For example, in a flow triggered by **Checkout started** with the default 5 minutes between enrollments, Laura starts a checkout at 10:00:00 and another at 10:00:10. The first one enters; the second is dropped and listed as "Per-contact frequency limit reached". Laura has one run. The **Simultaneous runs per contact** limit appears there as "Per-contact concurrent-flows limit reached", although what it counts is runs of this flow. If the trigger event is also one of the flow's exit events, each new occurrence ends the contact's current run and, if these limits allow it, starts a fresh one: that is how a win-back flow counts from the **last** order ([Goals and exits](/platform/en/automations/flows/goals-and-exits)). ![Re-entry and frequency settings of a flow's trigger](/platform/en/automations/flows/images/triggers-and-entry--2-reentry.png) *How often the same contact can enter this flow.* ## Enrollment pace **Enrollment pace** ("How fast contacts can enter this flow. It caps spend and protects you if more contacts qualify than expected.") sets two ceilings for the flow as a whole, whoever the contacts are: - **Enroll up to** *N* **contacts per hour**. - **Enroll up to** *N* **contacts per day**: a daily total; once it is reached, entry stops for the rest of the day. Both accept values from 1 to 100,000 and come pre-filled with a default. Size them to the volume you expect: a flow on **Order created** in a busy shop needs room, while a new flow you are still watching is safer with a modest ceiling. Your plan also caps how many contacts can enter per hour **across all the flows of the project**, and the pace of a flow can never go above that ceiling. The panel shows that figure under the hourly field. You can save a higher value, and the panel warns that it won't take effect beyond your plan's ceiling. How that ceiling works, and what changes when the account runs out of balance, is explained in [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). Contacts over any of these ceilings are dropped like any other entry over a limit, with their reason under **Didn't enter**. The same tab includes **Keep funds in your account**, which tells you what happens to entry into this flow if the account runs out of balance and, for users who manage billing, links to **Set up auto-reload** (see [Auto-reload](/platform/en/billing/wallet-balance#auto-reload)). The behaviour itself is described in [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards). ## When the contact enters: processing mode The contact doesn't enter at the exact instant the event arrives. **Processing mode**, the last section of the **Limits** tab, decides how long the flow waits before evaluating them, and you can pick one of two modes. **Consistent** (the default, "Typically under a minute, so out-of-order events can't skew a decision."). Entry waits a short **processing window**, so the audience, exclusions, event conditions and exit events read the contact's latest activity rather than a half-updated picture. In practice: - A contact who does one of the flow's exit events during the window (buys right after starting a checkout, for example) doesn't enter at all. - A message the flow would send during the window goes out when the window ends. - A **Fixed delay** counts from the event, so the window doesn't add to it: a flow that waits 30 minutes before its first message still sends about 30 minutes after the event. - When a flow receives a burst of traffic, entry can be held a little longer, but never beyond the waits the flow has before its first message, so the time at which messages are sent doesn't move. The flows list shows that maximum in the **Max. activation hold** column ("The longest a contact waits to enter when this flow gets a traffic spike. It never delays a message…"); see [Managing flows](/platform/en/automations/flows/managing-flows). **Instant** ("Starts right away. Recommended only for flows that need to send as soon as possible."). Skips the window: use it for one-time codes, quick confirmations and replies to inbound messages, where every second counts. Because nothing waits for the latest activity, it is only offered when it can't change a decision: - It isn't available when the flow filters its audience (anything other than **All audience**, exclusions included), when the trigger uses an event condition, or when the flow has exit events. The panel lists the reason under **Not available for this flow:**, for example "your flow filters its audience" or "your flow has exit conditions". - It may require a higher plan; if yours doesn't include it, the option shows **Upgrade plan**. - If you select **Instant** and later make the flow ineligible (say, by adding an exit event), the option shows **Requested, not active** and the flow runs with the processing window until you remove the blocker. - With **Instant** on, a flow with branches shows a warning: "This flow has branches, and they may not see the last few seconds of activity." A branch may route the contact as if their very latest activity hadn't happened yet. Nothing breaks, and the flow always runs. The contact journey records how each run entered, in **Entry timing** (**Processing window**, **Grouped by high demand**, **Instant processing** or **Manual run**); see [Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow). Test runs always enter immediately, whatever the mode; see [Testing, publishing and versions](/platform/en/automations/flows/versions-and-publishing). ## Example: the trigger of an abandoned-cart flow A shop wants to remind shoppers who start a checkout and don't finish it, without reminding anyone who has already bought: 1. **Trigger event**: **Checkout started**, with **Data source** set to the shop (so a tool relaying the same checkout doesn't bring the shopper in twice). 2. **Audience**: **Include** a segment of contacts with a mobile number; **Exclude segments**: a segment of customers who bought in the last two days, if the plan includes exclusions. 3. **Limits**: **Enrollments per contact limit** at **No limit**, **Minimum time between enrollments** at 1 day, **Simultaneous runs per contact** left at its default. 4. **Processing mode**: **Consistent**. The flow has an exit event, so **Instant** isn't available, and the window is exactly what keeps out a shopper who buys within moments of starting the checkout. 5. **Goal & exit**: **Order created** as an exit event, used as the flow's goal ([Goals and exits](/platform/en/automations/flows/goals-and-exits)). The steps after the trigger (a smart wait, the reminder and a follow-up with a coupon) are covered in [Waits](/platform/en/automations/flows/waits) and [Sending messages](/platform/en/automations/flows/sending-messages). ## Related - [Goals and exits](/platform/en/automations/flows/goals-and-exits) - Exit events, the flow's goal and the other ways a run ends. - [Monitoring a flow](/platform/en/automations/flows/monitoring-a-flow) - Who entered, who didn't and why. - [Limits and safeguards](/platform/en/automations/flows/limits-and-safeguards) - Plan ceilings, low balance and events that never start a flow. - [Segments](/platform/en/audience/segments) - Build the segments you include in or exclude from a flow. - [Attributes and events](/platform/en/audience/attributes-events) - The events your contacts generate and the data each one carries. - [Integrations & data sources](/platform/en/data-sources) - Where your events come from, and how to connect a new source. --- 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.