Flows

A flow is a sequence ARCY carries out inside your product on a user's behalf, such as inviting a teammate or verifying a domain. Each step points at a real element on a real page of your app. ARCY delivers the steps through the chat surface, so nothing is painted over your interface.

A flow is different from what Lift measures. Lift measures a path your users already take on their own. A flow is a path ARCY walks with them.

Creating a flow

Go to Flows and choose Create flow. Give it a name your team will recognize, and you land in the builder with an empty draft. Nothing you create is live until you publish it to an environment.

The flows list shows one publish state per flow for the environment selected in the sidebar, along with its step count and when it was last edited. The four views on the left narrow the list to pending changes, published, or unpublished flows.

Adding steps

Steps run in order, top to bottom. Each one does one of three things:

• Click, where ARCY activates an element such as a button or a link.
• Fill, where ARCY enters a value into an input. You write the question, and the agent asks the user for it. At run time your text is shown to the user word for word, so write a full, friendly question such as What is the name of your new project? rather than a fragment. The user answers in a small question card above the chat bar, ARCY types the answer into the field, checks that it fits, and moves on. See how a fill step asks its question. Use Insert attribute above the description to reference one of your attributes, such as the user's plan or company name. The reference is replaced with that user's real value when the flow runs, so What is the domain for {{ user.company }}? asks an Acme user for Acme's domain. A warning appears under the field if you reference an unknown or archived attribute, and a warning never blocks saving.
• Navigate, where ARCY opens a URL. Either a path inside your product, such as /settings/team, or a full https:// address. The URL takes attribute references too: type {{ in the field and pick from the list that opens, or press Insert attribute above it, and /orgs/{{ user.organization_id }}/settings sends every user to their own page, so one flow covers all of them instead of one flow per customer. An attribute shows in the field as a single highlighted chip rather than raw braces, and one press of Backspace or Delete removes the whole reference, so you cannot leave half of one behind. Unknown or archived attributes are flagged under the field, and a warning never blocks saving.

Use the arrows on a step to move it, and the bin to delete it. A flow holds up to 30 steps.

How a fill step asks its question

When a fill step runs, the question you wrote appears in a compact card just above the chat bar. The flow's progress row and the composer stay visible with it, so the user can see where they are, type an answer, or press Stop, all without the chat panel opening over the page the flow is working on.

The card matches the field the answer is going into:

• A plain text field takes the answer from the composer, as usual.
• A dropdown shows its options as tappable choices, so the user picks instead of typing.
• A date or time field shows a picker.
• A checkbox asks Yes or No.
• A password field shows a masked input. The value goes straight into the field on the page and is never stored, never added to the conversation, and never sent anywhere.

Checking the answer

Each fill step has an optional Expected input type: text, number, email, date, url, or phone. Set it when the field itself does not say what it accepts, such as a plain text input that really holds a date.

At run time the widget also reads the field's own rules, such as required, minimum, maximum, pattern, and maximum length, and applies both. An answer that does not fit is refused with a short error message and the question is asked again, until the answer is valid or the user presses Stop. The flow only continues on a valid answer, so banana can never land in a date field and quietly break the rest of the run.

While a question is waiting for an answer, the step's triggers pause. The answer and the Stop button are the only ways forward, so a trigger can never jump the flow past its own open question.

Choosing the element a step acts on

This is the part worth reading twice, because it is what makes a flow work months from now instead of only today.

You pick the element with Target Element, which opens your own product in a new tab with a picker turned on, so you can point at the element directly instead of typing a description of it. Click it and the element lands back in the builder straight away, along with the page you were on. There is no field to type a CSS selector into, and that is deliberate: ARCY identifies an element by a bundle of signals it records while you point at it, and a hand-typed description would not match any of them.

The button asks which page to open first. Give it the address of the page the element is on, or just a path such as /pricing when the environment has a single verified domain. ARCY checks that domain before it opens anything: a URL on a domain you have not verified for this environment is refused in the dialog, with the verified domains listed, and no tab opens.

A few things worth knowing:

• Your site needs a verified domain for the environment you are working in. Add one under Settings, verify it, and make sure it is assigned to this environment. Without that the button stays off, because there is no site ARCY is allowed to open.
• You are in your real, signed-in product. Nothing is simulated, so you can log in, open a menu, and pick something only your own account can see.
• Clicks do not activate your app while picking. Press Browse in the picker bar (or Alt+S) to click through normally, then switch back to Pick. Use this to open a dropdown and then pick something inside it.
• The picker bar never touches your page. Pressing Pick, Browse, or Exit changes nothing in your product. A dialog you opened in Browse mode stays open when you switch back to Pick, so you can pick a field or a button inside it.
• The link works once. If you reload the page or navigate to a different site, the session ends and you start it again from the builder.
• The tab closes itself once you pick. A step targets one element, so the pick ends the session: the element appears in the builder and the tab shuts a moment later, putting you back where you started. There is no confirm step.
• Give it the address of the page itself, not just your domain. If the address you enter redirects somewhere else, enter the address it ends up at instead.

Once an element is chosen, three settings control how ARCY finds it at run time:

• Matching decides how strictly ARCY scores candidates. Loosen it if ARCY cannot find the element. Tighten it if ARCY finds the wrong one.
• If several match picks which one to use when more than one element qualifies, counting from the top of the page.
• This element's text is dynamic tells ARCY to stop relying on the label, for elements such as "3 items in cart". ARCY finds the element by everything else it knows about it, and the step is still measured.

After a pick, the builder says how many elements on that page matched the target at that moment. It is there so you can see straight away that a target matches nothing, or matches forty things, and tighten it before you save. It never stops you saving, and it describes the page as it was when you picked: edit the target afterwards and the builder says so rather than quietly restating an old number.

When a target stops working

Copy changes, layouts get rebuilt, and a target that was right in March can be wrong in June. There are two ways to repair one, and both give ARCY an element from a real page rather than a description of one:

• Pick it again. Open the picker on the page and click the element. This replaces the target and takes a fresh screenshot.
• Approve the fix ARCY suggests. When a target stops matching on a live page, ARCY looks for what replaced it and offers it in the step, with how confident it is. Nothing changes until you approve it.

Letting ARCY repair it automatically

Each flow has a repair mode in its settings panel. The default, waiting for your approval, is described above. Turn on Repair automatically and ARCY applies a fix on its own when it is confident enough: the step's target is updated in both your draft and the published copy, and you get a notice in the dashboard and an email, so you can review the change even if you are not logged in. A fix below the confidence bar still waits in the approval queue, and you get an email for that too.

There is one safety rule on top: if a step keeps failing after an automatic repair, ARCY turns the flow back to approval mode by itself. A wrong guess can never loop.

Whatever the mode, ARCY only ever changes what a step points at. It never clicks a guessed element in a real user's session.

The element's text is shown but not editable, on purpose. Typing a new label would find the element again while quietly breaking the counting behind it, because what ARCY counts against is the element exactly as it was picked.

Step triggers

A step can carry triggers alongside its own action. A trigger watches a condition while the step is active, and when the condition becomes true it jumps the run to another step or dismisses the flow. Use one to skip a step the user has already done, or to route around a screen that only some users see.

A condition can look at:

• The page URL, matched against patterns where * stands for any text.
• What a text input holds. Besides the usual checks such as is, is not, and contains, the value supports is empty, is not empty, is greater than, is less than, and matches pattern, which uses the same * wildcard as page URL patterns.
• One of your attributes, with the same checks plus is greater than and is less than for numeric comparisons.
• An element's state: present or not, disabled or not, clicked or not, visible or not, checked or not, and focused or not.
• The time of day, between two clock times.
• Whether the user is idle, meaning they have made no click, key press, or scroll for a number of seconds you choose. Useful for offering help when someone seems stuck on a step.
• Whether this is the visitor's first visit to your product, or a return visit. Use it to show a longer path to newcomers and a shortcut to people who have been here before.

Conditions combine with And and Or, so one trigger can watch several things at once.

URL patterns and condition values, both a text input's value and an attribute's value, take Insert attribute the same way step fields do. The reference is rendered with the visitor's own values when the flow runs, so a pattern like /orgs/{{ user.organization_id }}/* matches each user's own pages.

One rule to keep in mind: while a fill step's question is waiting for an answer, that step's triggers pause. They resume from the next step on.

Flow settings

The panel beside the steps holds the settings that apply to the whole flow:

• Name is what your team sees.
• Public name is what your users see when ARCY offers the flow in chat. Leave it empty and the name is used. Insert attribute drops an attribute reference at your cursor, so Invite a teammate to {{ user.company }} reads as the visitor's own company name when the flow is offered.
• Summary is what the agent reads to decide when this flow answers a user's question. Describe the task it completes, not how it works. Insert attribute drops an attribute reference at your cursor, the same way it does on the Persona page.
• How long a step waits for its element is a limit, not a delay. A step starts as soon as the page can be read and acts the moment its element appears, so a fast page costs nothing here. The number is only how long a step keeps looking before it gives up and the flow stops cleanly. Raise it for a screen that loads slowly. There is no reason to lower it to make a flow feel faster.
• Repair automatically decides what happens when a step's target breaks on a live page: wait for your approval, or let ARCY apply a confident fix on its own. See letting ARCY repair it automatically.

Marking the finish

Turn on This step completes the flow on the step a user reaches when they are done. Only one step can carry it. If you mark none, the last step counts as the finish.

The step still runs. A click marked as the finish is clicked, a navigate marked as the finish navigates, and the flow ends after that, not instead of it.

This matters for measurement: it is what "completed" means when ARCY reports how far users get.

Measuring a flow

ARCY counts every flow you build. It reports how far real users get, step by step, and where they stop. There is no toggle and nothing to switch on.

What it counts is your own product, not ARCY. Each step points at an element or a page in your app, so the count includes users who did the task on their own and never opened the widget. That is the point: a number that only counted people ARCY helped could never tell you whether ARCY helped.

Which steps are measured

Not every step can be counted, and the ones that cannot are left out of the funnel rather than guessed at:

• A click step is measured, by the element it points at.
• A navigate step is measured when it opens a page in your own product. A link to another site is not, because ARCY records nothing there. Neither is a URL that reads as a wildcard, such as one with a * in it or a /:id segment: those are patterns rather than addresses, and counting one would sweep in pages the step never opens.
• A fill step is never measured. Nothing observes a field being filled, so what proves the user got through a form is the button they press next. Put a click step after the fill and the funnel picks it up there.

When a flow has no funnel

Measurement never blocks a save. A flow you cannot measure saves and runs like any other, and the settings panel says why it produces no funnel:

• Fewer than two measurable steps. A drop-off needs two points to fall between.
• The step that completes the flow cannot be measured. If the funnel ended a step earlier than the flow does, its last number would read as "completed the flow" while meaning "reached the last step before it". Add a click or navigate step after it, or mark a different step as the finish.

Where a flow's funnel appears

A flow's funnel is read on Lift. It is read-only there: the flow builder owns the steps, so drop-off is always a reflection of your current flow, never something you edit separately.

You do not have to go looking for it. Once a flow is saved, the builder shows a View on Lift button next to Save, and the flow's row on the Flows list carries the same link in its actions menu.

While the flow's steps stay the same, the numbers keep accumulating. Renaming the flow or a step changes nothing: names are not what ARCY counts. Changing which element or page a step points at is a different question about your product, so the count starts fresh from there.

Deleting a flow

Deleting a flow removes its funnel from Lift with it, so you are never looking at a funnel for something you removed. A flow cannot be deleted while it is published anywhere, so unpublish it everywhere first.

Saving

Saving is a single, explicit action, and it saves the whole flow. Every step has to be finished first: a step with no name, no element, or no URL blocks the save, and the builder lists exactly what is unfinished.

Saving a flow that is already live somewhere moves those environments to Pending changes: they keep serving the copy you published, not the one you just saved. The Publish panel says so as soon as the save lands, and it stays said until you publish again.

If someone else on your team saves the same flow while you have it open, your save is refused rather than quietly overwriting theirs. The builder says so and offers to reload. Your edits stay on screen, so copy anything you need before reloading.

Previewing a flow

Preview, next to Publish in the builder, runs your saved draft on your real page before any customer sees it. It opens your product in a new tab the same way the element picker does, and the widget performs the flow there for real: real clicks, real navigation, the flow name and step progress in the widget, and a stop control. Nothing is simulated, so what you watch is exactly what a user would get.

Four things to know:

• Preview runs the saved draft, not the published copy. That is the point: you test a change before releasing it. It is disabled while you have unsaved changes, for the same reason Publish is, so what runs is always what you see on the canvas.
• Preview runs as you. An attribute reference such as /orgs/{{ user.organization_id }}/settings resolves to your own values, the ones your product sent through identify() for the account you are signed in with, so a navigate step lands on your page rather than on an empty one, and a fill step asks its question with your name in it.
• Preview runs never touch your numbers. Your own testing does not appear in the flow's analytics.
• Preview never gates Publish. You can publish without previewing; an unreachable test page never blocks a release.

The preview link works once and expires after a few minutes. If the tab was reloaded or the link is stale, start it again from the builder.

When a flow cannot continue

Products change, and sometimes a step's element is not on the page: it was removed, renamed, or simply never appeared. When that happens the step keeps looking for the flow's How long a step waits for its element window, and if the element still is not there the flow stops cleanly. The user sees a plain apology in the chat, in their language, and the composer stays active, so their next move is just to ask the agent. No spinner, no retry loop, and ARCY never clicks an element it merely guessed.

Every stop like this is recorded: it appears in the flow's analytics as an error with element-not-found broken out, and it is what starts the repair path.

Publishing

Saving does not put a flow in front of anyone. Each environment serves its own copy, and it serves nothing until you publish to it.

The Publish panel at the top of the builder lists every environment, where the flow stands in each, and when it was last published there. Each environment has its own button, because publishing is per environment: publishing to Staging changes nothing in Production.

A flow is in one of four states in a given environment:

• Never published, so the environment has never served it.
• Published, so the environment is serving exactly what you last saved.
• Pending changes, so the environment is serving an older copy than your saved draft. Publish again to bring it up to date. This is the state to watch: without version history it is the only sign that your users are getting something other than what you last saved, so the Publish panel names every environment that is behind and how old its copy is, and the flows list says how many flows are behind in the environment you are looking at.
• Unpublished, so the environment served it once and someone took it out.

Publishing overwrites, and there is no way back. There is no version history and no rollback: a flow you publish by mistake is fixed by editing and publishing again, or by unpublishing it. That is why the confirmation names the environment, what it is serving now, and what you are about to send it. Read it.

Two things stop you publishing, and the panel says which:

• Unsaved changes. Publishing sends the saved flow, not what is on your screen, so save first and the two agree.
• A flow with no steps. It would appear to your users and then do nothing.

Unpublishing

Unpublish takes the flow out of one environment. Users there stop being offered it right away. The flow itself, and everything you have authored in it, is untouched, and publishing again brings it straight back. Use it the moment a live flow misbehaves: it is the fastest way to stop it, and it does not need your work to be finished or saved first.

A flow that is live anywhere cannot be deleted. Unpublish it everywhere first.

Flow analytics

Once a flow is live, Pulse answers whether it is working. All numbers are per environment and follow the date range picker at the top of the section.

The Flows section of Pulse opens with three programme-level numbers and two charts: how every run ended, day by day, and one bar per flow. Below them is a row per flow: how many users started it, how many completed it, the completion rate, the step losing the most people, errors, and a small trend line. The whole section is explained on Pulse. Each row opens that flow's own page, which you can bookmark and share. The builder links there too, from the compact numbers next to Publish.

The flow's page tells one flow's whole story:

• The step funnel, with how many users entered and completed each step, and where the biggest drop is. Users who closed the flow on purpose are counted apart from users who simply went quiet and walked away, so you can tell a boring flow from a broken one. The walk-aways are shown on the step where they stopped.
• Median time to complete. The middle value, not the average, so one tab left open overnight cannot distort it.
• Errors, with element-not-found broken out, next to the flow's self-heal history, so breaks and repairs read as one story.
• How runs started: from the starter suggestions, from the agent offering the flow in a conversation, or from the widget's drawer.
• Agent suggestions: how often the agent offered this flow, how many offers were accepted, how many of those runs finished, and a log of each offer with the page it happened on and a link to the conversation it came out of.

Small samples are treated honestly: below a minimum number of runs the raw counts still show, but no step is singled out as "the" drop-off.

This page is about a flow ARCY performs. The other measurement, how much a flow lifts a path your users walk on their own, still lives on Lift.