An Action Flow is built the same way as a Flow: you select elements in your own app and Userflow records the sequence. The difference is what each step does — instead of showing a tooltip, each step performs an action.
Before you start, you need a published Resource Center with an Adoption Agent block. Without one, you can build an Action Flow but you won't be able to preview it. See Resource Center Implementation Guide.
Step 1: Create the Action Flow
- Select Action flows in the sidebar and create a new action flow.
- Enter a name. This is the internal name you'll see in lists.
Step 2: Write the summary
The Summary of action flow field is the single most important thing you'll fill in. It is the only context Adoption Agent has for deciding when to recommend this flow.
A Flow carries its own content — headings, body text, button labels — and the Agent reads all of it. An Action Flow has none of that. It's a sequence of clicks on elements, so the summary is the only description of what the flow actually does.
Describe the exact task the flow performs on the user's behalf, in the words a user would use to ask for it.
- Too thin: "Add a team member"
- Better: "Automatically provisions a new team member, assigns their workspace permissions, and sends an invitation."
The flow will still work with a thin summary. What suffers is recommendation accuracy — the more Action Flows and Flows you add to an Adoption Agent, the more the summary determines whether the right one gets picked. Come back and refine it if you find the Agent surfacing the wrong flow.
Step 3: Set the wait time
Wait time before grabbing content is how long the Agent will keep trying to find the element for a step before it gives up. The default is 30 seconds.
This is a timeout, not a countdown shown to the user. It exists so a run can't hang indefinitely — without it, the Agent would keep retrying and the user would be stuck until they closed the widget.
Match it to what the step is doing:
| Step type | Suggested wait time |
|---|---|
| Clicking a button or link that's reliably present | 2–3 seconds |
| Steps that depend on a page or panel loading | 5–10 seconds |
| Steps where the user has to type something substantial | Longer — the timer covers the time they spend typing |
Set it too low on a step that waits for user input and the run will time out while the user is still typing. Set it high and the user can always click Cancel instead of waiting.
When the wait time is exceeded, the Agent stops trying, the run ends there, and the user is told the step couldn't be completed.
Step 4: Set the public name
Public name is what your users see on the card Adoption Agent shows when it recommends this flow. Write it as the task, from the user's side: "Add a team member," not "Team member provisioning v2."
Step 5: Build the steps
Each step is one action. Add a step, choose what it should do, then point it at an element. Steps can click an element, enter text, or make a dropdown selection.
- Click Select element and pick the element in your app. The simulator loads your app so you can click directly on the target, the same way you select elements for a Flow.
- If the element is hard to reach through the selector, use Go manual to enter the selector yourself.
For steps that need something only the user can supply, add an input step and describe what the Agent should ask for. You're writing a prompt for the Agent, not the exact question — it will phrase the question itself, ask in the chat, and confirm what it received before continuing. Describing the information you need is enough: "Ask which event the user wants to track."
See Selecting elements for element selection technique, which works the same as it does in the Flow builder.
Step 6: Connect the steps with triggers
Steps aren't connected automatically. Each one needs a trigger that says where to go next, added with + Add Trigger.
This is the part most people miss on their first Action Flow. If a step has no trigger, the run stops there.
Two things to know about how conditions behave in an Action Flow:
- Conditions are evaluated after the step's action runs, not before. The Agent performs the click, then checks conditions to decide which step comes next. This is different from a Flow, where matched conditions can send a user straight to a later step.
- An always-true condition is fine when you don't need branching. If every user should follow the same path, a trigger that always evaluates to true just means "go to the next step." Use real conditions — a segment, an attribute — only where the task genuinely forks.
As a best practice, add a trigger with a dismiss action on your completion step so the run closes cleanly.
Step 7: Preview and publish
- Preview the flow to watch it run end to end. This needs the published Resource Center with an Adoption Agent block described above.
- Publish when it behaves the way you expect.
Publishing an Action Flow does not make it available to users. It has to be added to an Adoption Agent as a source first — see Add an Action Flow to your Adoption Agent.