Limits and safeguards

Most of what a flow does is up to you: which event starts it, who can enter, how long each wait lasts. Around those choices sit a few boundaries that you can't change, and a set of protections that work on their own. The boundaries keep every flow finite and readable — a contact always reaches the end of a flow within a known time, and a journey never grows into something nobody can follow. The protections keep a project from sending what nobody intended: messages about orders placed months ago, a flood of entries when a data source sends thousands of events at once, or spend that carries on when the account has run out of funds.

This page gathers them in one place, for when you plan a long or large flow, when you want to know what your plan changes, or when you are working out why a flow didn't start for someone. The entry limits you configure yourself — how often a contact can enter and how many contacts enter per hour or per day — are explained with the trigger, in The trigger: who enters and when.

At a glance

Each value is explained on the page in the last column.

Limit	Value	Explained in
Shortest wait	1 minute; only the window of a Timezone delay or Smart delay can start Right away	Waits
Fixed delay	1 minute to 90 days	Waits
Wait for activity	1 minute to 90 days; up to 10 branches plus No interaction	Waits
Timezone delay and Smart delay window	As early as from Right away to 14 days; As late as from 8 hours to 14 days	Waits
Wait for delivery	Up to 48 hours	Waits
Longest path through the flow	180 days	Below
Steps per flow	50	Below
Exit events	Up to 10	Goals and exits
Branches in a split	Up to 10, plus the default branch	Branches
A/B split	Up to 10 variants plus the default branch; at least 1 % per variant and 2 % for the default branch	Branches
Enrollments per contact limit	No limit or Once only	The trigger
Minimum time between enrollments	5 minutes by default; from 1 minute to about 115 days	The trigger
Simultaneous runs per contact	5 by default; 1 to 10	The trigger
Enrollment pace of a flow	Per hour and per day, 1 to 100,000 each	The trigger
Active flows per project	Set by your plan	Managing flows
Entries per hour across the project	Set by your plan	Below
Live test	About 10 % of the contacts who enter	Testing, publishing and versions

How long a flow can run

Every flow has a maximum duration: the longest time a contact can spend inside it, following the slowest possible path from the trigger to the end. The panel works it out from the waits on each path:

• a Fixed delay counts its full length;
• a Timezone delay or a Smart delay counts the end of its window (As late as);
• a Wait for activity counts its time limit (How long to wait), because a contact who never reacts stays until it runs out;
• a Wait for delivery counts about two days.

Messages, branches and contact updates take no time in this count. Where the flow splits, each branch is a separate path: the waits inside one branch add up with the waits before and after the split, but never with the waits of a sibling branch, because a contact only goes down one of them. The maximum duration is the total of the slowest path.

That total can't exceed 180 days. A flow whose slowest path is longer can be saved as a draft, but it can't be published: Fix your flow to publish it lists the problem for the whole flow, Flow can run up to N days on its longest branch, over the 180-day limit. Shortening any wait on that path solves it; the others don't matter. (How the panel lists what blocks publishing is explained in Building a flow.)

You can check the figure for every flow in the flows list: the Max. duration column shows "The longest a contact can stay in this flow, following its longest path of waits." See Managing flows for the list and its columns.

For example, an abandoned-cart flow starts with a Smart delay whose window ends at 8 hours, sends a reminder, then waits up to 1 day with a Wait for activity. Contacts who don't click go through a Fixed delay of 1 day before a second reminder; contacts who click go straight to the end. The slowest path is the one without a click: 8 hours + 1 day + 1 day, so the flow's maximum duration is about 2 days and 8 hours. A win-back flow built as Fixed delay of 90 days, a message, a Wait for activity of 60 days and, on No interaction, another Fixed delay of 45 days, adds up to 195 days on its slowest path: it can't be published until one of those waits is shorter.

A long maximum duration also means contacts stay on a version for a long time: when you publish a new version, the contacts already inside finish on the one they entered (see Testing, publishing and versions). Keep flows well under the limit when you can: a journey that needs months is usually easier to manage as two flows, the second one starting from something the contact does.

How big a flow can be

A flow can have up to 50 steps. Every step you add from the palette counts — messages, waits, splits, contact updates, Goal reached and Exit flow — wherever it sits on the canvas. The trigger counts as one step too, and so does each exit event.

When a flow gets close to the limit, the toolbar shows a notice such as 42 of 50 steps, with the hint "This flow is close to the 50-step limit. Consider splitting it into smaller flows. It publishes normally up to the limit." The notice doesn't block anything. Above 50 steps the flow can still be saved as a draft, but it can't be published: Fix your flow to publish it shows The flow has N steps, over the 50-step limit.

A flow that grows that large usually mixes several journeys. Splitting it makes each part easier to test, read and measure. A common way to chain two flows: the first one ends with an Update tags step that adds a tag, and the second one starts when a contact gains that tag (the Customer created / updated event with a condition on the added tag). See Updating the contact and Tags, lists and new contacts.

Plan limits

Your organization's plan sets two ceilings for Flows, both counted per project. The panel shows your figures where they apply, and the plan comparison in the panel lists them as Active flows per project and Event flow enrollments per hour.

Entries per hour across the project

Your plan caps how many contacts can enter flows per hour, adding up every flow of the project. It is a shared budget: a busy flow uses up room the other flows of the same project would have had. The count runs per clock hour (from 10:00 to 10:59, for example) and starts again at the next hour.

The panel shows your ceiling in the trigger's Limits tab, under the hourly field of Enrollment pace: "Your plan allows up to N enrollments per hour across all the flows in this project." Each flow's own pace still applies inside that ceiling, and it can never exceed it. You can type a higher hourly value for a flow, and it is saved, but the panel warns "… is above your plan's ceiling of N per hour. It won't take effect beyond that." (How a flow's own pace works is explained in Enrollment pace.)

When the project reaches its ceiling, every flow in it stops taking entries until the next hour. The contacts who qualify in the meantime are dropped, not queued: they don't enter that time, nothing is retried later, and each one is listed under Didn't enter with "Project hourly limit reached (plan limit)" (see Monitoring a flow).

For example, during a flash sale a shop receives far more orders than usual. Its Thank you for your order flow and its Ask for a review flow both start on Order created, so each order uses two entries of the project's hourly budget. If the budget runs out at 10:40, from then until 11:00 no flow in the project takes entries — not the thank-you, not the review request, and not the abandoned-cart flow either. To protect the flows that matter most at peak times, give the less urgent ones a lower Enrollment pace: a flow stops at its own hourly cap before it can use up the shared budget. If your project reaches the ceiling often, a plan with a higher ceiling gives every flow more room; the plan comparison in the panel shows each plan's Event flow enrollments per hour.

Active flows per project

Your plan also sets how many flows can have their entry open at the same time in each project. Flows with enrollment paused (Pause enrollment, the same action as Disable in the flows list), drafts and archived flows don't count. How the limit behaves when you publish, pause or change plan is explained in Managing flows.

What plans don't limit

Plans set speed and simultaneity, not volume. There is no monthly allowance of runs: a flow can run as many times as its trigger fires, within the hourly ceiling. Runs themselves aren't charged, and neither are waits, branches, contact updates, goals or exits. What is charged are the messages a flow sends, like any other SMS or RCS message; see Sending messages.

When the account runs out of funds

Flows send messages that are paid from the organization's balance, so they react when the account has no funds left. Instead of stopping completely, every flow slows down to a much reduced pace until funds are back.

What happens while the account has no funds:

• Entry into each flow drops to a reduced pace. The trigger's Limits tab shows the exact figure in its Keep funds in your account section: "Without funds, entry into this flow drops to N contacts per hour." While it is happening, the same section says so: "Your account has no funds, so entry into this flow has dropped to N contacts per hour."
• The contacts over that pace don't enter. They are listed under Didn't enter with "Hourly entry limit reached: the account has no funds". As with every other drop, they aren't queued: they enter only on their next qualifying event, once the account has funds again.
• Contacts already inside aren't slowed down by this entry limit. Whether the messages they reach can still be sent depends on the balance when the step runs; the contact journey shows what happened at that step (see Monitoring a flow).
• The whole organization is affected. The balance belongs to the organization, so every flow of every project slows down at the same time.
• Your team is notified. The owner and the team members with Full access, Billing or Marketing receive an email and an SMS saying that the organization's flows have stopped for lack of balance, at most once a day. Despite that wording, entry has slowed down rather than stopped, and contacts already inside carry on.

As soon as funds are back in the account, the normal pace returns, with nothing else to do. To keep it from happening, turn on auto-reload: users who manage billing see a Set up auto-reload link in the same section, and the settings are explained in Auto-reload.

If messages from your flows are missing and entries have slowed down at the same time, check the balance first.

A locked project — for billing or a suspension — is a different case. No flow in it takes entries: each contact is listed under Didn't enter with "Project locked (billing/suspension)". The contacts already inside don't move on to their next step while the lock lasts, and a run that stays blocked for too long is ended.

Without enough balance, a flow's messages aren't guaranteed to go out: keep the balance topped up or turn on auto-reload, as described above.

Events that never start a flow

A flow starts from events that are happening now. Some events reach your project without being new — they describe something that happened earlier, or they arrive as part of a bulk load — and they never start a flow, whatever the trigger says. The data isn't lost: the events are stored on the contact's profile and you can use them in segments and reports. They just don't trigger any flow.

• Events with an old date. An event whose own date is well before the moment it reaches Instasent — a historical order loaded to complete a contact's history, a backfill, events from a queue replayed long after the fact — doesn't start a flow. Without this, loading last year's orders would send a thank-you message for each one. If you send events through the Ingest API, its guide explains the time window it uses: Automations and the event time window.
• The first sync of a newly connected source. When you connect a shop or another integration, the contacts and events it brings in the first import don't start flows. Events that arrive after that, as they happen, start flows as usual.
• CSV and copy-paste imports. Contacts and data loaded through CSV & copy-paste import never start a flow, including the tags and lists an import adds.
• Events that can't trigger a flow, because of their type or their data source, and events from a different data source than the one selected in the trigger. The events that can start a flow are listed in Which events can start a flow.

Flows also need a Platform project: an A2P Messaging API project doesn't run them.

None of these events gets as far as the flow's entry checks, so they leave no row in Didn't enter and nothing in the flow's activity (see What leaves no trace).

For example, a shop imports a CSV of 2,000 past customers and gives them all the tag vip. A VIP welcome flow that starts when a contact gains the vip tag doesn't run for any of them, and a Welcome new contacts flow doesn't run for them either, even though they are new contacts in the project. Customers who get the vip tag later, through the shop's live connection or a flow's Update tags step, do enter. To reach the imported customers once, send them a campaign (see Campaigns).

Protections against bursts

Separately from the pace you set, the platform protects the project when a lot arrives at once:

• Load protection. If a very large number of entries arrives across the project in a very short time — typically a data source sending a bulk update of many contacts at once to a flow that starts on Customer created / updated — the protection drops part of them. They appear under Didn't enter as "Dropped by the project's load protection". Those rows are a sample, not one per dropped contact. Spreading bulk updates out over time, and adding event conditions so that a flow only reacts to the updates it needs, keeps a flow clear of it.
• Two events of the same contact at the same moment. If the same contact sends two qualifying events for a flow within a few seconds, only the first one is evaluated. The second appears under Didn't enter as "Another activation for this contact was in progress" and isn't retried. This mostly happens when a source sends the same action twice in quick succession.
• The same event delivered twice. An event that reaches the flow twice never creates two runs: the repeat is listed as "Already has an execution for this event".

The thresholds behind these protections aren't configurable and aren't shown in the panel. What you control is the flow's own pace and re-entry limits, in The trigger: who enters and when.

What Flows doesn't limit

Two protections that people often expect don't exist in Flows, by design. Knowing it helps you build around them.

There are no quiet hours on messages. A Send message step sends as soon as a contact reaches it, at any hour. Flows has no project-wide quiet hours and no sending window on the message itself. To keep messages out of the night, place a Timezone delay or a Smart delay before the send; see Waits.

There is no frequency cap across flows. Each flow decides on its own who enters, and nothing checks whether another flow, or a campaign, has just messaged the same contact. If two flows start on the same event, a contact who matches both enters both and gets both flows' messages. Simultaneous runs per contact doesn't help here: it only counts runs of the flow where you set it.

For example, a shop has a Browse reminder flow on Product added to cart and an Abandoned cart flow on Checkout started. A shopper who adds a product and then starts a checkout enters both, and could get two reminders about the same purchase. To keep the flows from overlapping:

• Make one flow end where the other begins. Add the other flow's trigger event as an exit event: with Checkout started as an exit event of the browse reminder, a shopper who reaches the checkout leaves the browse reminder and continues only in the abandoned-cart flow. See Goals and exits.
• Exclude contacts who are already in another journey. Tag contacts when they enter a flow (with an Update tags step at the start), and exclude a segment of that tag in the other flow's audience with Exclude segments, if your plan includes it. See Who can enter: the audience.
• Use one trigger per journey. When two journeys start from the same event, build them as one flow and route contacts with a split instead of running two flows side by side; see Branches.

Related