The trigger: who enters and when

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). 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.

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 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) and the Check entry event step can route on it (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.

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.

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. 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).

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. 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).

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.

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:

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). 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).

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.

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). The behaviour itself is described in 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.

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. Test runs always enter immediately, whatever the mode; see Testing, publishing and versions.

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).

The steps after the trigger (a smart wait, the reminder and a follow-up with a coupon) are covered in Waits and Sending messages.

Related