Customer Flows

​

What is a customer flow?

A customer flow describes one type of customer conversation: who the customer is, what they want, the variants you need to cover (language, mood, environment), and the agent expectations the agent is graded against. Flows live under Simulate → Customer flows in the sidebar. Today, flows drive simulations — you attach them to run plans and Roark generates test calls from them. The same definition is what live-call analytics will grade incoming traffic against next. Every flow has:

---

​

Authoring modes: Improv vs Scripted

Each flow is authored in one of two modes, toggled with the Improv / Scripted pill in the editor header. Switching modes is non-destructive: both data shapes coexist on the flow, so you can toggle back and forth. If the other mode already has authored content, the editor asks you to confirm the switch — your work is retained either way.

​

Improv mode

The improv editor is organized into three numbered sections:

1. Happy path — the customer setup: a free-text brief describing the situation the customer is in, what they want, and how they typically behave. This section also carries the happy path’s Persona, Environment, and Variables chips, and a Link preceding flow control (see flow composition below).
2. Agent expectations — the required agent picker plus expectation rows, inherited by every variant.
3. Edge cases — additional variants that inherit from the happy path and override only what differs.

​

Scripted mode

Scripted mode replaces the form with a full-screen canvas where you author the conversation as a graph of steps. See the scripted graph for step kinds and rules.

---

​

Variants: happy path and edge cases

A variant is one per-caller configuration of the flow: a title, persona, environment, variables, per-variant labels, and optional additional expectations.

• Exactly one variant is the default — the happy path. It must have a customer setup and a persona.
• Every other variant is an edge case. Edge cases inherit the happy path’s setup, persona, and environment unless they override them. The setup field on an edge case reads “Inherited from the happy path — type to override.”
• Additional expectations append. An edge case can add expectations that apply just to that variant; they never replace the flow-level set.
• Each edge case can carry its own labels, and its menu lets you Mark as happy path (making it the new default) or Delete edge case.

​

Persona, Environment, and Variables chips

Every variant carries a chip strip configuring who’s calling and from where:

• Persona — the simulated customer’s voice and delivery. The happy path requires one (a new flow auto-seeds the built-in Polite First-Time Caller persona, falling back to your project’s first persona); the picker can also create or edit personas inline. See Personas.
• Environment — background noise played under the customer’s voice: Silent, Office, Coffee shop, City street, Driving, Airport, Children playing, or Thunderstorm. Edge cases also get an Inherit option.
• Variables — per-variant key/value entries (name, account ID, last visit…) handed to the customer-side model so it can answer the agent’s questions consistently. Add rows manually, or use Apply a test profile to replace the entries with a saved profile’s properties. Prompt and step text support {{variable}} tokens with autocomplete — {{name}} for flow-scoped properties, {{persona.name}} for persona-scoped ones. See Variables.

---

​

Agent expectations

Agent expectations are the graded contract of the flow: short, LLM-evaluated instructions like “Agent greets warmly and uses the caller’s name once.” After each simulated conversation, Roark checks the transcript against every expectation and reports pass/fail per expectation, per call.

• Flow-level expectations are inherited by every variant.
• Additional expectations on an edge case apply only to that variant, on top of the flow-level set.
• In scripted flows, expectations are also derived from the agent turns along each path — what you wrote the agent should say becomes what it’s graded on.

Write expectations as specific, checkable statements. “Agent offers a callback when the customer declines to hold” grades cleanly; “Agent is helpful” doesn’t.

---

​

Labels

Flows use a single label system with two kinds:

• System labels — Roark-curated: Adversarial, Multilingual, IVR, Voicemail. These drive template behavior; for example, the Red teaming template automatically runs flows carrying the Adversarial label.
• Custom labels — free-form tags for your own organization.

Labels attach at the flow level and per edge case, and the hub filters by them (alongside a Mode filter for Improv vs Scripted).

---

​

The scripted graph

In scripted mode you build the conversation as a directed graph rooted at a start node. Click Add step to insert a step, then connect steps with edges; selecting a node opens an inspect panel with its kind-specific fields.

​

Step kinds

​

Graph rules

• Branching is allowed — give a step multiple outgoing edges to fork the conversation.
• Merges are allowed — branches can rejoin.
• Cycles are blocked — the graph must be a DAG, so a conversation always terminates.

​

Paths derive variants

Every unique route through the graph from start to finish is a path, and when you save the flow, Roark derives one variant per path — each path card in the right rail shows a generated description of its route. You don’t hand-author scripted variants; you shape the graph and the variants follow. You can still control who runs each path: Add variant for path creates an extra copy of a path that runs it with a different persona, environment, or variables. The rail marks the flow’s default variant with a Default badge and groups the rest under Edge cases, with Make default and Delete variant available per variant.

---

​

Composing flows

Flows compose in two directions:

• Flow link (scripted → scripted). A scripted flow can include a Flow link step that splices another scripted flow’s steps in mid-graph. Use this to reuse a shared segment — an IVR menu, an identity-verification exchange — across many flows. Only scripted flows can be linked this way.
• Preceded by (scripted → improv). An improv variant’s Link preceding flow control names a scripted flow — and optionally a specific variant of it — that runs before the improv segment. Typical use: navigate a scripted IVR tree deterministically, then improvise the conversation once a human-like agent picks up.

Improv has no deterministic end, so an improv segment can only ever come last — you can’t link into an improv flow from a scripted step.

---

​

Creating a flow

From the hub, click New flow to open the chooser at /customer-flows/new. You can generate a draft or start blank: Generate — from existing material (each opens the Ask Roark assistant with a seeded prompt):

• Describe what you want — tell Ask Roark the conversation in plain language and it drafts the flow.
• From a transcript — upload or paste a transcript and Roark turns it into a flow.
• From your calls — pick real calls from your production traffic to base the flow on.

Or start blank:

• Improv — Describe the customer opens the brief editor.
• Scripted — Author the conversation opens the graph canvas.

Variants drafted by Ask Roark carry a Generated badge until you review or promote them.

---

​

Using flows in a run

Flows drive simulations through run plans. In the create-run page, the Attach flows picker lists your library; expand a flow to choose its variants. Each attachment carries:

• A variant selection — all variants, the default variant (happy path) only, or specific variants you pick.
• An optional persona override — run the flow as a different customer without editing it. The Multilingual template uses this to fan one flow out across language personas.
• Variable overrides — per-attachment {{variable}} values that win over the variant’s stored values at run time.

When a run starts, it snapshots the attached flows and variants, so the report always reflects exactly what was tested — even if you edit the flow afterwards.