Prompt & flow builder

Design branching conversations as a visual flow - every node, transition, global setting and AI helper explained in plain language.

Real conversations branch. “Are you the account holder?” → if yes, continue; if no, end politely. “Interested?” → qualify, then book; not interested → take a callback time. Every OyeHello agent - call, chat or WhatsApp - is built as a flow so it can handle those forks.

A flow lays the conversation out as a map: boxes (we call them nodes) joined by arrows (transitions). Each node is one step with its own short instruction; each arrow is a rule for when the agent moves from one step to the next. The agent starts at the greeting and walks the map, turn by turn, based on what the customer actually says.

This is the flow builder (also called the multi-prompt builder). Drag nodes around a canvas, wire them together, and click any node to edit it in the panel on the right.

How you get here

Create an agent (see Create an agent) and it opens straight into the flow builder:

From a template - the template’s full flow is already on the canvas, ready to edit.
From scratch - the canvas is empty. Click Create starter flow for a tiny Greeting → Close flow to build on, or click Generate and describe the conversation so the AI drafts it (see Generate a flow with AI).

Everything you do here autosaves as a draft. Nothing reaches a real customer until you Publish, so explore freely - you can’t break anything live by editing.

The top bar has everything you’ll use:

Generate - opens the Flow editor chat: describe a new flow, or ask for changes to the current one in plain words.
Node - add a step to the flow.
Outcome board (inbound call and WhatsApp agents) - opens the agent’s outcome board.
Settings (gear) - agent-wide choices: voice, language, knowledge base, compliance pack, behaviour switches, global rules and intents, variables, and what happens after the call. See Agent settings.
Test - try the draft in a side panel before anyone else hears it.
Issues (warning badge with a count) - opens Issues to fix. Only shows when there’s something to fix.
Lock / Unlock - only the agent’s creator sees this. See Lock an agent.
Publish - or Republish when a live agent has unpublished changes, plus Unpublish to take it offline.

The canvas

The canvas is the map. Each node is a card showing its name, type and goal. To work with it:

Add a node - click Node. Name it, pick what it does, and (optionally) pick an existing node it should be reached from, with the condition for that arrow.
Connect two nodes - drag from a node’s bottom handle to another node. That drops an arrow you then describe in the inspector.
Edit a node - click it. The right-hand inspector opens with everything about that node.
Move things around - drag cards to lay the flow out however reads best. Positions are saved.
Auto-layout - click Auto-layout on the canvas to arrange every node top-to-bottom in conversation order. Right after, an Undo layout button puts your own arrangement back. The builder never rearranges a flow you laid out by hand unless you click it.
Issue badges - a node with a problem shows a small badge on its card, so you can spot it on the map.

Tip: lay the flow out the way the call actually runs - greeting at the top, the happy path flowing down, “not interested” branches off to the side. A tidy canvas is far easier to reason about when something misbehaves.

Node kinds

Every node has a kind that tells the agent what job it’s doing on that step. The kind also decides which extra settings appear in the inspector. Here’s every one.

Greeting

Opens the call. The agent introduces itself, says who’s calling and why, and gets the caller’s consent to continue. Every flow starts on a greeting (it’s the one node you can’t delete, and it can’t be a silent or closing kind).

Tip: keep it to one or two sentences. The greeting sets the tone; a rambling opener loses people before you’ve made your point.

Conversation

(Called Talk in the Add node window.) A free back-and-forth toward a goal. This is your workhorse node - the agent talks naturally with the caller to accomplish one thing: qualify a lead, explain a product, handle an objection, pitch the offer. Most flows are mostly conversation nodes.

Tip: one job per node. “Qualify and pitch and book” is three nodes, not one. Small nodes are easier to wire, test, and fix.

Collect

Captures one specific value from the caller - a date, a number, a yes/no, a name - and stores it in a variable you can use later. The agent asks clearly, once, confirms the answer, and moves on. See Collecting values below for its extra settings. On a website chat or WhatsApp agent, a Collect node can also ask for a document - see Ask for a document.

Tip: use a collect node whenever you need the answer saved as data (to route on it, put it in a report, or send it to your CRM). If you just need the agent to chat, use a conversation node.

Decision

(Called Decide in the Add node window.) Routes silently - no speech. A decision node doesn’t say anything to the caller; it just looks at the values you’ve already collected and picks which way to go. Use it to branch cleanly on data: if score ≥ 700 → premium offer, else → standard offer.

Important: because it never speaks, every arrow out of a decision node must be exact - a Rule over variables or a Business hours window. An “intent” arrow here would be ignored. The builder flags this for you.

Action

Performs a tool - fetch availability, book a slot, look something up in your CRM. The agent briefly tells the caller what it’s doing (“Let me check that for you…”), runs the tool, and continues. You choose which tool(s) it can use in the node’s Runs on card.

Tip: if a tool returns something you want to reuse later (an available time, an order status), map its result into a variable so a later node or rule can read it.

Transfer

(Called Hand to a human on a chat agent.) Hands the caller to a human. The agent stays brief and doesn’t promise a specific outcome, then connects the call to one of your approved transfer numbers.

Pitfall: always give a transfer node a fallback arrow. If the transfer can’t complete - line busy, nobody available, caller declines - the call needs somewhere to go, or it gets stuck re-prompting. The builder warns you when a transfer node has no fallback.

Distress handler

A system safety net for upset callers. This one is special - you add it from the Safety net section of the Add node window, and you don’t wire it into the flow like the others. See The distress handler below for the full picture. Add one to any flow that talks to real customers.

End

Closes the call with an outcome - booked, not interested, wrong person. The agent says a brief, warm goodbye and hangs up. A flow can (and usually should) have several end nodes, one per way the call can finish.

Pitfall: an end node hangs up right after it speaks - so it must be a goodbye, never a question. If your end node says “…and what time works for you?”, the agent asks it and then immediately disconnects, so the answer is lost forever. Put the ask on a collect or conversation node before the end. The builder warns you if an end node looks like it’s asking for something.

Transitions - how the call moves

A transition is an arrow leaving a node: when this happens, go there. Each one has a kind that decides how it fires.

Intent

Fires when the caller’s reply matches something you describe in plain language. You write what the caller says or wants - “the caller agrees to a demo”, “asks about pricing”, “wants to reschedule” - and the agent judges each turn against it.

This is the one you’ll reach for most, because it handles the messy reality of how people actually talk.

Write conditions the caller can say, not steps the agent takes. A good intent describes something observable in the caller’s words: “the caller confirms the address”, “the caller says they’re not interested”. A weak one describes the agent’s own progress: “finished pitching”, “explained the offer” - the agent can’t hear those, so the arrow never fires reliably. Ask yourself: could I tell this happened just by listening to the caller? If yes, it’s a good condition.

Rule

Fires when an exact expression over your variables is true - no interpretation, no AI judgement. Things like score >= 700, interested == true, age < 18. Rules are checked deterministically, so they’re perfect for routing on hard data you’ve already collected.

Tip: a rule must be a real comparison, not a sentence. consent == true works; “the caller agreed” does not (that’s an intent, not a rule) - the builder will flag prose written into a rule.

Retries

Fires after the node has re-asked this many times without getting anywhere. It’s your escape hatch. Set it to 2 and, after two failed attempts on a step, the agent gives up on that step and follows this arrow instead of nagging forever.

Tip: every collect node should have a retries arrow pointing somewhere sensible (a callback, a polite close). Without a give-up path, a caller whose answer never quite matches could be re-prompted endlessly. The builder warns you about this exact trap.

Business hours

Fires when the current time is inside (or outside) a weekly window. Pick the Days, the Open and Close times and a Timezone (for example Asia/Kolkata), then choose Inside or Outside. Use it to send callers down an open-hours path or an after-hours path - “during opening hours → transfer to the desk; outside → take a callback time”. It’s checked exactly, with no AI judgement, and works on a decision node too.

Handoff (advanced)

Hands the live call to a different published agent - the caller stays on the line, and the new agent takes over with everything collected so far. Useful when a specialist agent should finish the call (e.g. billing questions go to your billing agent). You describe when to hand off in plain language and pick the target agent.

How the agent chooses

After each turn the agent checks a node’s arrows in a fixed order, so behaviour is predictable:

Rules - exact checks on your variables.
Business hours - the time-window check.
Intent and Handoff - the node’s own plain-language conditions first, then your global intents.
Retries - only when nothing above matched and the node has re-asked enough times.

Within each group the first match wins, so put your most specific conditions first. If no arrow matches, the agent stays on the current node and re-engages the caller - it won’t wander off the map.

Collecting values

Give a collect node an Extract card in the inspector, where you tell it exactly what to capture:

Variable - the name it saves the answer under (e.g. credit_score, callback_at). Later nodes read it with {credit_score}, rules compare against it, and it lands in the call’s saved data.
Type - how to interpret and clean up the answer: Text, Date and time, Number, Phone, Email, Yes or no, or One of a list. Picking the right type means “next Tuesday” becomes a real date and “seven hundred” becomes 700, so your rules compare like-for-like.
Options (for “One of a list” only) - the exact set of allowed answers. The caller’s reply is matched to one of them.
Retries before giving up - how many times to re-ask before following the node’s retries transition instead of looping.

Name variables the way your CRM does (interested, callback_at, preferred_slot) so the data lines up when you sync it out. And remember: the value is only saved if the caller actually gives a usable answer - a blank stays blank, which is exactly when the retries path should catch it.

Ask for a document

Website chat and WhatsApp agents can ask the customer to send a document - an ID card, a bill, a certificate - and check it before moving on. Set a Collect node’s Type to Document, then fill in the Document card:

Document - what to ask for, for example Aadhaar card. You can use {variables}.
Hint for the checker - optional: what it looks like or where things are on it.
Parts - for example front and back. Leave it empty for a single page or photo. If the customer sends only one part, the agent keeps it and asks for the rest.
Fields to read - details to read off the document into variables, such as the name or date of birth. They are saved only when the document is verified.
Rules - up to five plain-English checks, one per line, for example The name matches {customer_name}. A rule passes only when the checker can point to it in the file.

The node’s Status variable is set to verified, unverified or failed:

verified - the right document, readable, every part and every rule. The flow moves on.
unverified - the file could not be checked (for example a Word or Excel file, or a temporary problem). The customer is never stuck: the flow moves on, and you can add a rule like id_status == "unverified" to route these to your team. A customer who moves on without sending a document is also recorded as unverified (“moved on without a document”).
failed - the customer sent a wrong or unreadable document too many times (Retries before giving up, 3 by default). The flow follows the node’s retries arrow, usually to a person.

What counts as a try:

A question or a plain reply on this step never counts - the agent answers and asks again.
A partial upload (one part of several) does not count either.
A file sent earlier in the chat, or while a teammate held it, is picked up when the step is reached. A file sent twice is skipped.

Aadhaar numbers are always masked (XXXX XXXX 1234) everywhere they appear. Checking a document costs nothing extra; it is part of the conversation.

Your team sees each document in the inbox and on the contact’s record (a Documents card), with its files and the details read off it, and can Mark verified or Reject it there. Only teammates who can read the inbox can open the files; marking or rejecting needs edit access. Call agents can’t ask for documents.

Custom variables

Variables are the flow’s memory - named slots that hold values as the call moves along. You declare them in Settings → Rules, intents, variables → Variables, and only declared variables can be used in a prompt ({name}) or a rule (score >= 700). The builder warns you if a prompt or rule mentions a variable you never declared.

Each variable has an origin that says where its value comes from:

From the CSV - filled in per call from your calling list, before the call even starts. This is how one flow says “Hi Priya, about your order #4821…” to one caller and the right details to the next. The column must exist in your list, or the value arrives empty.
Collected in call - captured by a collect node during the conversation.
Written on end - produced by a tool result during the call (see the Action node).

Inside a node’s Prompt, use the insert variable menu to drop a {variable} at your cursor - no need to type the braces or remember exact spelling.

Persona lives in Settings, not in your prompts. Voice, tone, and language are set once in Settings and apply to every node - so a node’s prompt should describe what to do on this step, not repeat “be friendly and speak Hindi.” Keep prompts short and task-focused.

Per-node settings - the “Runs on” card

Each node picks its own reply model and tools, and can inherit or override the agent’s knowledge base. This is where a flow earns its keep - a cheap, fast model for the greeting, a careful one for the tricky reasoning step, and only the tools each step actually needs.

Reply model - which AI generates this node’s replies. Every node picks its own; a new node defaults to Fast (Haiku), which is right for most scripted turns. Switch a node to an accurate model when it needs careful reasoning. Mix and match freely across nodes.
Knowledge base - Inherit from agent, None (this node quotes nothing), or a specific knowledge base. Point a node at your real docs so it answers a caller’s question from your actual content instead of guessing.
Tools available here - the tools this node may use, chosen per node. Nothing is selected by default, so a node has no tools until you add them. A tool the node can’t see, it can’t call - everything else stays off no matter what the caller asks. This is how you make sure the “book a meeting” tool only fires on the booking step, not during the greeting. For a transfer node you can also narrow which numbers it may hand the call to; for CRM tools, which integrations it may touch.

Grant the least each node needs. Every extra tool on a node is one more thing that could fire at the wrong moment. Turning tools on step-by-step (rather than agent-wide) is the whole point of a flow - use it.

Silence timeout

Below the transitions, each node can have its own silence timeout: if nobody speaks for N seconds, follow this arrow - with an optional Reprompt once before following. Handy on a collect node - if the caller goes quiet after you ask for their date of birth, nudge once, then route to a fallback rather than sitting in dead air. Leave it off and the agent’s normal silence handling applies.

Capturing data and wrapping up a call

Every real call needs two things at the end: the data you wanted, and a clean, tagged finish. A flow does both with the pieces you’ve already met, so here’s how they fit together.

The data you walk away with

Capture is deliberate and lives on the nodes:

Each Collect node saves one value into a variable (callback_at, credit_score, interested).
With Auto-collect details on, the agent also fills declared variables whenever the customer mentions them, on any step.
Those variables, plus anything filled from your CSV and any tool results (Custom variables), are the call’s saved data - what you filter, report on, and sync out afterwards.
While you Test, watch the “Captured so far” panel fill in turn by turn, so you can confirm each value lands before you ever dial.

One Collect node per thing you need to keep, and name the variables the way your CRM does - that’s the whole capture story in a flow.

Tagging how it turned out

Every finished call gets an outcome that places it on your outcome board. After the call, the platform reads the transcript and picks the matching column - you don’t have to build anything for it. You can also attach the Set disposition tool to a step before the end (in its Tools available here) so the agent tags the outcome itself as it wraps up.

If a caller asks not to be contacted again, attach the Opt out tool so the request is recorded across your workspace. Tools are per-node - put them on the steps where they’re needed, not on every node.

Landing the call

Give each way the call can finish its own End node with an outcome and a short goodbye. Remember an end node hangs up right after it speaks, so collect anything you still need on a Collect node before it.

Wrap-up checklist: capture what you need on Collect nodes (or with auto-collect) → record opt-outs with the Opt out tool → land every path on an End node.

Sending outcomes onward

Two places send that data to your other tools once the conversation ends:

Settings → After the call - for each connected CRM or Google Sheet, log the call or create a lead. Connect the tool first under Integrations.
Outcome board column actions - notify a teammate, call a webhook, send a WhatsApp or push to your CRM when a call lands in a column. See Dispositions & outcomes.

The flow’s job is to capture; where the data goes next is set there.

Global rules

Settings → Rules, intents, variables → Global rules holds “never do this” guardrails that are folded into every node, on top of the platform’s own safety baseline. Write them once instead of repeating them in each prompt:

Never promise a specific delivery date.
Always confirm the caller’s name before continuing.

One-click starters (+ Never quote a price, + Verify before account details, + Confirm name first) add common rules for you. Global rules save with the flow, so they reach live calls when you publish.

Global intents

Global intents are things a customer can say at any point to jump to a step - no need to wire the same arrow from every node. Each one is an If condition in plain language plus the node to go to:

If the caller asks for a person → your Transfer node.
If the caller asks you to repeat that → the step that explains the offer.

A node’s own arrows are still checked first; a global intent is the fallback that works everywhere. Add them under Settings → Rules, intents, variables → Global intents with Add global intent.

Auto-collect details

Normally a value is saved by a Collect node that asks for it. Turn on Settings → Behaviour → Auto-collect details and the agent also picks up your declared Collected in call variables whenever the customer mentions them, on any step - so a caller who says “I’m Ravi, call me back Friday” in the greeting has both filled already, and the flow doesn’t ask again. The setting shows which variables it’s watching for. It adds a small check each turn until they’re all filled.

The distress handler

This is a built-in safety net, and it behaves differently from every other node - so it’s worth understanding on its own.

You add it, but you don’t wire it in. Add it from Node → Safety net → Distress handler. There are no arrows into or out of it. Instead, the call jumps to it automatically whenever the caller:

is genuinely distressed or upset,
asks to speak to a human, or
stays frustrated with the automated agent past a short de-escalation budget (the agent tries to calm things and re-orient a couple of times first; only if that fails does it escalate).

When it triggers, the handler warmly acknowledges the caller and offers to connect them to a person. Then:

Caller says yes → it does whatever tool you attached to it. By default that’s a transfer to a human. If you attach the end call tool instead, it simply ends the call gracefully - no transfer.
Caller says no → the call resumes exactly where it left off. Nothing is lost.

A flow can have exactly one distress handler (the builder stops you adding a second). Add one to any flow that talks to real customers - it’s the difference between a caller who feels heard and one who’s stuck arguing with a robot.

Tip: if you turn on the transfer behaviour, make sure your transfer numbers are set (in the handler’s “Runs on” card or at the agent level). A distress handler that offers a human with nobody to receive the call is worse than none.

Generate a flow with AI

Short on time, or not sure where to start? Click Generate in the top bar. The Flow editor opens: describe the conversation in a sentence or two - “Call leads who booked a demo, confirm they still want it, collect a preferred time and book it; otherwise take a callback time” - and the AI drafts the whole flow.

Before you see it, the AI stress-tests the draft against difficult callers: someone interested, someone curious who asks questions first, someone not interested, someone for whom it’s a bad time, a sceptical caller who asks who’s calling and how you got their number, and someone who wants a callback. It checks every one of them reaches a proper end, then fixes the weak spots. It also adds a distress handler for you.

Always review and test what it generates. It’s a strong first draft, not a finished call. Read every node and arrow, tweak the wording to sound like you, and run a test before publishing.

Chat with AI to edit your flow

The same Flow editor chat edits an existing flow in plain words: “add a step that asks for the pincode before booking”, “make the greeting shorter”, “if they say they already ordered, end politely”.

@mention a node to point at a specific step.
The nodes it changed are highlighted on the canvas.
Undo this change or Restore this version on any reply to go back. Both replace the draft, so you’re asked to confirm.
While the AI is working, editing the canvas is paused so nothing clashes.
Edits go into the draft. If the agent is live, a Republish bar appears in the chat so you can push the change to live calls without leaving it.

Issues to fix

The builder checks your flow as you work. When something needs attention, a warning badge with a count appears in the top bar - click it to open Issues to fix.

Issues are grouped by area - Structure, Collect, Routing, Variables, Endings and Connections - and filtered by All, Blocking or Warnings.
Blocking issues stop you publishing: a dead-end node, a collect node with no variable, a decision node with a non-exact arrow, a required variable that nothing fills.
Warnings don’t block publishing but are worth a look: an unreachable node, a path that never ends, a transfer with no fallback, a rule that reads like a sentence, a possible re-ask loop.
Each card has a button that takes you straight to the fix - the node, the variables, the global intents, your transfer numbers or your integrations.

When the list is empty it says Ready to publish. The same checks run in the publish checklist below, and the AI in the Flow editor can see them too, so you can ask it to fix them.

Test, then publish

Test first, always. Click Test in the top bar:

Simulate - type as the caller and watch the flow light up node by node and arrow by arrow, with a Captured so far panel showing each value as it lands. Free, and the fastest way to check routing.
Voice (call agents) - talk to the draft through your laptop microphone. No phone call, no publishing.
Test call (call agents) - have the agent ring your own phone.

On a website chat or WhatsApp agent, use Attach file in Simulate to send a test document (up to 5 MB): the panel shows what the check found. Test files are never stored.

Chat agents get Simulate; WhatsApp agents can also test on their phone. See Test your agent.

When you click Publish, the Publish this flow checklist runs. Anything under Must fix before publishing has to be fixed first; Worth a look items don’t block you. It also shows green checks when things are clean - every node reachable, every path ends, compliance pack attached, voice and language set.

Once published, the agent shows LIVE and is used on new calls. Change something later and the top bar shows Unpublished changes - click Republish to push it. Campaigns already running stay on the version they started with, so an in-flight campaign never changes mid-run. Unpublish takes a live agent offline; the published flow is kept, so publishing again brings it back.

Keep flows shippable

Every path should reach an end node, so the call always has a clean finish.
Add a distress handler to any customer-facing flow.
Give every collect node a retries (give-up) exit so a caller can’t get stuck.
Keep node instructions short and specific - one job per node.
Write intent conditions the caller can be heard saying, not steps the agent takes.
Test the branches, not just the happy path - the “no”, the silence, the “wrong number” are where calls go wrong.

Next: Voice & language →