Testing, publishing and versions

Every flow has two sides. The draft is the one you edit, on the flow's Build tab; the published versions are the ones contacts actually run. Nothing you build reaches anyone until you publish it, and publishing never moves the contacts who are already in the flow: each of them finishes the version they entered with. Between editing and publishing for everyone there are two safety nets. A test run puts one contact of your choice through the saved draft so you can read exactly what arrives, and a live test gives a new version to about 10% of the contacts who enter, so you can compare it with the current one before deciding.

Publishing is always done by a person, in the dashboard. Iris and integrations that use the Product API can prepare a flow and leave its draft ready for you, but testing it, publishing it, switching its entry on or off and archiving it happen here, on the flow's page.

Test with one contact

A test run answers the question you have before publishing: what will a contact actually get? It runs the saved draft for one contact, from the trigger to the end, so you see the real text with its variables filled in, the links, the branch the contact takes and the order of the messages, on a real phone.

The Test run button sits in the toolbar of the Build tab, and only appears when the draft is saved and has no errors. While there are unsaved changes, Save changes and Discard take its place; while the draft has errors, the toolbar shows Fix your flow to publish it instead (see Building a flow). That rule guarantees that the test always runs exactly what is on screen.

Set up the test

Test run opens the dialog Run the flow for one contact, which explains that it "runs the saved draft on the real engine, so you can read what arrives before publishing" and that it "stays out of your stats and version history". It has these rows:

• Contact — who runs the test. The list opens on your Test contacts: the contacts that carry the tag test-contacts. To add one, search for the contact and star it; the star adds that tag to the contact in your audience, so it is waiting in the list the next time. You can also add the tag by hand, written exactly like that in lowercase. It is an ordinary tag: it shows on the contact like any other.
• Event — appears only when the flow's messages use event variables (_event.*), such as the order number or the cart link. The panel preselects a real, recent event of the trigger's type, and you can change it or remove it. Its data fills the event variables of your messages. It does not decide branches: a split that looks at the entry event takes its default branch unless you pin it under Branches. Without an event, those variables come out empty in a message that is still sent.
• Branches — appears only when the flow has splits. Select opens Select branches for the test run on the canvas: click a step to make the test reach it, or click a branch label to send the contact out through that branch. Branches you don't pin decide on their own, with the contact's real data. Pinning is how you walk every path of a flow with the same contact: run it, pin the other branch, run it again. If you edit the flow afterwards and a pinned branch no longer fits, the panel drops it and says so.
• Messages are sent for real and charged — the last row, as a reminder.

Next to Run flow, at the bottom of the dialog, the Auto-skip waits checkbox is on by default. Waits that only count time (Fixed delay, Timezone delay, Smart delay) pass straight through, so you don't wait days for the next message. Waits that listen for something (Wait for delivery, Wait for activity) keep waiting, because ending them early would invent an answer; for those, use Skip on the step while the test runs.

Select Run flow to start.

Follow the test

The run starts straight away: test runs enter immediately, whatever the trigger's processing mode. The canvas switches to the test view, which paints the contact's path on the flow with the status of each step. A step where the contact is waiting shows when it will fire and a Skip button. Skip ends that wait as if its time had run out: on a Wait for activity the contact leaves through No interaction, and on a Wait for delivery through Not delivered, if the message still has no delivery result. To test a branch that reacts to the contact, tap the link or reply from the test phone instead.

The toolbar of the test view offers:

• Details — opens the contact journey, the step-by-step record of the run (see Monitoring a flow).
• Cancel execution — while the run is still going, stops the contact where they are.
• Run again — opens the dialog again with the same choices (contact, pinned branches), to repeat the test after a change.

To go back to editing, select the Build tab. The test runs a snapshot of the draft as it was saved, so you can keep editing while it runs without changing what it does. Only the latest test is kept: it stays under Last test run, the first section of the archive box at the end of the tab strip, with the contact's name and the run's status, and the next test replaces it.

What a test run checks and what it doesn't

• Entry is skipped. The contact you choose enters directly: the trigger's event conditions, its audience and the re-entry limits aren't checked. To see whether a real contact would enter, look at the flow's activity once it is published (see Monitoring a flow).
• Everything after entry is real. Each message goes through its consent policy and the contact's subscription like any other, so if the test contact can't receive a message, the journey shows that step as not sent and why. Update tags, Update lists and Manage subscription steps change the test contact for real too.
• It stays out of your figures. A test run doesn't count in the flow's statistics and gets no version number. The flow's activity lists it with Preview as its version and Test as the way it entered.
• It does count towards the contact's re-entry limits. The flow's limits look at every run of the flow, the test included. Right after a test, the contact is within the Minimum time between enrollments; while the test is running, it is one of their Simultaneous runs per contact; and it counts as one of their entries for the Enrollments per contact limit, so with Once only that contact doesn't enter for real while the test is on record. A test leaves no permanent mark: it counts only while its run is kept (14 days), and after that it stops counting. If a test contact then triggers the flow for real and appears under Didn't enter with "Per-contact frequency limit reached" or "Per-contact re-entry limit reached", this is why (see Monitoring a flow).

Each message a test run sends is charged like any other message a flow sends; waits, branches and contact updates cost nothing.

Publish

Publishing turns the saved draft into a numbered version that contacts run. There are two destinations: everyone who meets the entry conditions, or a small group of them as a live test (explained below).

1. 1

   Save the draft

   Select Save changes. The Publish button only appears when the draft is saved, has no errors and differs from what is live. The Build tab tells you when there is something to publish: it shows an amber cloud icon whose tooltip reads Unpublished changes.

2. 2

   Open the Publish menu

   Select Publish in the toolbar of the Build tab. The menu offers two options, each with the share of contacts it reaches:

   • Publish to everyone — tagged 100% (or 90% while a live test is running): "From now on, every contact that meets the entry conditions runs this version."
   • Publish to a small group — tagged 10%: starts a live test, explained in Live test: try a version on about 10%.
3. 3

   Confirm

   For Publish to everyone, the panel asks Publish draft to Live?: "The draft becomes the active version. Contacts already inside finish on their current version; new contacts enter the new one." Select Publish. The panel confirms with Draft published to Live.

The new version appears on the Live tab with its number (v1 the first time). The Build tab keeps a draft with the same content, ready to be the starting point of your next change, and the cloud icon disappears until you save something different.

When the Publish button isn't there

The panel shows Publish only when there is something valid to publish. If it's missing, the reason is one of these:

• There are unsaved changes. Save changes and Discard sit in its place; save first.
• The draft has errors. The toolbar shows Fix your flow to publish it with the list of problems (see Building a flow).
• The draft is identical to what is live. There is nothing new to publish, which is also why the Build tab shows no cloud icon.
• The flow is archived, or your user can only view automations. An archived flow is read-only (see Managing flows).

The first publish switches entry on

A new flow is created with its entry off, and its header reads Draft. The first time you publish it — to everyone or to a small group — entry switches on by itself: the header changes to Active and the switch reads Enrollment active. If you're publishing, you want the flow to start.

Later publishes leave the switch as it is. If you paused the flow with Pause enrollment (the same action as Disable in the flows list), it stays paused after you publish a new version, and nobody enters until you select Activate enrollment.

There is one exception to the first publish. If the project already has as many active flows as its plan allows, the version is published but entry stays off: the header reads Enrollment paused and nothing at publish time says why. The reason appears in the tooltip of the entry switch. Pause another flow to free a slot and then activate this one; the limit is explained in Managing flows.

Publishing costs nothing. What is billed is each message the flow then sends, as explained in Sending messages.

Contacts already inside keep their version

Every run is tied to the version the contact entered on, and follows that version to the end, even if you publish newer ones in the meantime. Contacts who enter after you publish run the new version. The version you replaced is archived, but publishing cancels nothing in it: the contacts still inside carry on, step by step, until they finish. The one exception is a version that has been archived for about three months, counted from the day it was archived: the platform then retires it, and its remaining runs end as Canceled, as explained in Monitoring a flow.

This is why you can change a flow that is running without affecting the contacts already inside. A contact halfway through a three-day wait never lands on a step that no longer exists, or on a branch you've reorganised: the path they started is the path they finish. In the archive box, each archived version shows how many contacts are still inside it, and the flow's activity shows the version of each run (see Monitoring a flow).

The flip side is that a fix doesn't reach the people already inside. For example:

1. Your Ask for a review flow waits three days after an order is delivered and then sends a message with the review link. Version v1 is live.
2. You notice a typo in the message. Two customers are in the middle of the three-day wait.
3. You fix the text on the Build tab, select Save changes, then Publish › Publish to everyone. The fix becomes v2.
4. Every customer who enters from now on gets the corrected text. The two customers who were already waiting are still on v1, so when their wait ends they receive the message with the typo.

If those messages must not go out, stop the old version's runs: open v1 from Archived versions in the archive box and use the cancel button next to N inside now to Cancel executions. Its contacts stop where they are and receive nothing else; they don't move to v2, so they won't get the corrected message either. How cancelling works, and how to stop a single contact, is explained in Managing flows.

Pausing the flow doesn't stop them either: Pause enrollment closes the entry, while the contacts inside finish their journey and their messages are charged.

Versions and the tab strip

A flow keeps several versions at once, each with a role. The roles are permanent and there is at most one of each:

Role	What it is	Numbered
Draft	The only editable version, on the Build tab. Saving replaces it. Contacts never run a draft.	No
Live	The version that every contact who meets the entry conditions runs.	Yes
Live test	A version published to a small group: it runs for about 10% of the contacts who enter, next to Live.	Yes
Preview	The snapshot of the draft that a test run uses. It never appears in the version history.	No

Archived is not a role but a state. When a Live version is replaced, or a live test ends, that version keeps its role, gains an archive date and becomes read-only. Its contacts finish, its figures stay available, and you can republish it or load it into the draft at any time (see Go back to an earlier version).

Version numbers — v1, v2, v3… — are given when a version is published, to everyone or to a small group. Live and live test share the same count, and a number is never reused. Every publish creates a new version with the next number, including promoting a test and republishing an old version, because both publish a copy. For example: v4 is live and you start a live test, which becomes v5. When you promote it, the copy that goes live is v6, and v4 and v5 are archived.

stateDiagram-v2
    state "Live test" as LiveTest
    [*] --> Draft: new flow
    Draft --> Live: Publish to everyone
    Draft --> LiveTest: Publish to a small group
    LiveTest --> Live: Promote to 100%
    LiveTest --> Archived: test archived or promoted
    Live --> Archived: replaced by a newer version
    Archived --> Live: Republish to everyone
    Archived --> LiveTest: Republish to a small group
    Archived --> Draft: Edit as draft
    class Live success

Every publish, republish or Edit as draft creates a copy: the version it starts from stays where it was.

The tab strip

Below the flow's name, a strip of tabs says at all times which versions exist and which one you're looking at:

• Build — the draft. An amber cloud icon (Unpublished changes) appears when the saved draft differs from what is published.
• Live — the live version, with its number. While a live test runs, it also shows 90%.
• A second Live tab, with a flask icon and 10% — the live test, while one runs. The panel calls it Live test where you start or end it.
• The archive box, the last icon on the strip. Its menu has two sections: Last test run, the latest test with its contact and status, and Archived versions. The number next to Archived versions counts the archived versions that still have contacts inside. Each row shows the archive date, the version number and how many contacts are still inside; versions with contacts inside come first, then the most recent. It lists up to 20 versions.

The version number on each tab is a coloured pill: green while entry is active, grey while entry is paused, and amber once archived. A flow with nothing published, archived or tested shows only the Build label, without a strip.

Each tab offers what makes sense for that version, and the rest sits in the ⋮ menu next to it:

Tab	Main action	In the ⋮ menu
Build	Edit, Test run, Publish	—
Live	None: it is read-only, and shows the flow's figures	Edit as draft
Live at 10% (live test)	Promote to 100%	Edit as draft, Archive test
An archived version	Republish	Edit as draft

The figures shown on the Live tabs and on archived versions are explained in Flow analytics.

Publish state in the flows list

The flows list sums up each flow's versions in its Publish state column:

State	Meaning
Published	There is a Live version and the draft is identical to it.
Unpublished changes	There is a Live version and a saved draft that differs from it.
Draft	Only a draft; nothing has been published yet.
Empty	The flow has no versions yet.
Live test · 10%	A live test is running.

Live test: try a version on about 10%

A live test lets you try a change on real traffic while limiting who sees it: a new text, an extra reminder, a different wait. The new version runs for about 10% of the contacts who enter; the rest keep running Live. You compare how the two perform and then decide whether the change goes to everyone.

To start one, select Publish › Publish to a small group on the Build tab. The panel asks Start a live test on 10%?: "About 10% of contacts that meet the entry conditions run the test version; the rest stay on Live. It sends for real and takes about 10% of Live's reach while active." Confirm with Publish to a small group; the panel shows Live test started on ~10%, and the flows list marks the flow Live test · 10%.

Who is in the test group

• About 10% of the contacts who meet the entry conditions. The share is fixed: you can't change the percentage or choose a segment as the test group.
• The split is per contact, not per entry. The same contact always lands on the same side, so someone who enters several times while the test runs always gets the same version.
• There is no fallback to Live. The split happens before each version checks its own audience. A contact in the test group who doesn't meet the test version's audience doesn't enter at all; they don't run Live instead. Keep this in mind if the test version changes the audience.
• It shares the flow's limits. The live test doesn't add capacity: Live and the test count against the same Enrollment pace, and if the flow reaches it, both sides are trimmed in proportion.
• It is real traffic. The test version sends real messages, and its runs, goals and conversions count in the flow's figures like any others.

A flow with nothing published yet

If the flow has never been published, Publish to a small group works as a soft launch: only about 10% of the contacts who meet the entry conditions enter, and the rest don't run anything yet. The confirmation reads Launch to 10% of contacts?: "This flow has nothing published yet, so only about 10% of contacts that meet the entry conditions enter it. It sends for real. Publish to everyone when you're happy with the results." As a first publish, it also switches the flow's entry on.

While the test runs

You can keep working on the draft. Two things happen if you publish it again before the test ends:

• Publish to everyone replaces Live — the option shows 90% — and the live test keeps running next to the new Live.
• Publish to a small group replaces the running test: the old one is archived and its runs finish on it.

How Live and the test compare — runs, goals, conversions, with a check of whether the difference is significant — is explained in Flow analytics.

End the test

Open the live test's tab (Live with 10%) and choose one of two endings:

• Promote to 100% — the button on that tab. The panel asks Promote the test to everyone?: "Sends 100% to the tested version and ends the test. Running executions finish on their version." It publishes a copy of exactly the tested version as the new Live, with a new number, and archives the test. The panel confirms with Test promoted to everyone.
• Archive test — in the tab's ⋮ menu. The panel asks Archive the test?: "Archives the test version and sends 100% back to Live. Running test executions finish on their own." It confirms with Test archived. In a soft launch there is no Live to go back to, so archiving the test means the flow stops running for everyone.

If the test version no longer passes the editor's checks, the tab shows This version has errors and can't be published. in place of Promote to 100%.

Example. Your Abandoned cart flow sends one reminder, and v4 is live. You want to know whether a second reminder with a discount code brings more orders. You add it on the Build tab, save, and select Publish to a small group: the test becomes v5, and about one in ten shoppers who start a checkout get two reminders, while the rest keep getting one. After a couple of weeks you compare goal rate and revenue in the flow report. If the test wins, Promote to 100% makes the copy v6 live for everyone; if not, Archive test sends everyone back to v4.

The live test is billed like Live: each message its contacts receive is charged, and nothing else.

Go back to an earlier version

Archived versions are kept, so you can return to one if a change didn't work out. Open it from the archive box › Archived versions; it opens read-only with its own figures. From there, there are two ways back.

Republish an archived version

Republish opens the same menu as Publish:

• Publish to everyone — "A copy of this version goes live for every contact that meets the entry conditions." The confirmation, Publish this version to everyone?, adds that "contacts already inside another version finish the journey they entered on."
• Publish to a small group — "A copy of this version starts a live test on a small group of the contacts that meet the entry conditions." The confirmation is Start a live test with this version?; if a live test is already running, it adds "The current live test is archived and replaced."

Either way, what gets published is a copy with a new number. The archived version stays archived, and your draft isn't touched. The button isn't offered, and a sentence takes its place, when there is nothing to publish — This version already matches Live — or when the version no longer passes today's checks — This version has errors and can't be published. In that case, load it into the draft, fix it there and publish it.

Example. On v3 you changed the wait of your Welcome new contacts flow, and fewer people are converting. You open v2 from Archived versions and select Republish › Publish to everyone. A copy of v2 goes live as v4. The contacts who entered on v3 finish it, unless you cancel its executions.

Edit as draft

Edit as draft, in the ⋮ menu of any published or archived version (Live included), copies that version into the draft so you can start your next change from it. The panel asks Replace your draft with v2? (with the version you chose): "Your draft will be replaced by a copy of v2. What's published doesn't change." It confirms with Draft replaced with a copy of v2.

Use it to undo experiments on the draft and go back to what is live, or to rebuild on top of an older version. Your current draft is overwritten, including any work you haven't published, and nothing reaches contacts until you publish the draft again.

Related