Flow Journey: the story of one call through every Architect flow it touched

A complaint lands with the service desk at ten past nine: a customer rang, chose the option to track an order, waited, and was cut off. An agent elsewhere asks a related question about a different call: why did this one land in my queue rather than Billing's? Both questions have exact answers. Genesys Cloud recorded what every Architect flow did on those calls, step by step. The difficulty is getting from a conversation ID to an answer a Support Engineer can paste into the ticket in five minutes.

That is the job of Flow Journey. Paste one conversation ID and it shows every flow the call passed through, in order, with every prompt the caller actually heard, every key they pressed and how long they hesitated, every lookup that hit or missed, every branch, transfer and exit. It deliberately does one conversation at a time, and it does it in the open: nothing is reconstructed from today's configuration, everything comes from what the runtime recorded on that call.

Genesys provides strong native tooling here, and we use it. When historical execution data storage is enabled, Architect's Execution History lists previous instances of the flow you have open, and the Query Builder on the Flow Execution History tab searches by criteria such as conversation ID, flow ID, or error and warning codes, one criteria item at a time. Clicking an instance opens Replay Mode, which plays the instance back over the flow design with step in, step over, step out, breakpoints, a timeline and keyboard shortcuts. For a flow author debugging a design, it is the right tool.

Replay Mode is anchored in the flow: you replay one flow instance inside that flow's editor, and the flow is read-only while you do. A real call is often several instances. A conversation that runs the main inbound call flow, calls a bot flow and waits in an in-queue flow produces one instance per flow entered, and the question the complainant asks spans all of them. People who need the answer, such as support engineers, team leaders and testers, are also often not the people who live in Architect every day.

Every execution of a capturing flow writes a flow instance: metadata such as the flow name, type, version, start and end time and error or warning reasons, plus a downloadable trace whose core is an ordered list of single-key step objects, startedFlow, actionPlayAudio, menuMenu, actionDataTableLookup, actionSwitch, actionCallTask, actionTransferToAcd, endedFlow and so on. Each entry carries timestamps, the output path the runtime took and, depending on the execution data level, variable values and action inputs and outputs.

The conversation ID is the thread that ties those instances together. Query the flow instances API for a conversation and Genesys returns the instances that conversation produced, up to 200 per query; prepare a download job and each instance's trace becomes available to fetch. Put them in start-time order, unwrap each step, and the call's journey appears, across flows, bots and in-queue handling, as one continuous story. The figure shows that convergence: one ID, several Genesys objects, one view.

The server assembles each journey live in four steps. A query to the flow instances API filtered on the conversation finds every instance; a job request with data actions expanded asks Genesys to prepare presigned download links for up to the first 50 instances; the job is polled for up to about 24 seconds until it succeeds; and each instance's trace is downloaded, five at a time, with a failed download recorded against that instance rather than failing the whole call. If the job is still preparing, the page says so and still shows which flows the call touched.

No conversation data is stored. There is no database and no trace retention: every journey is fetched fresh, normalised and rendered in the browser, and closing the tab discards it. Only an encrypted sign-in credential and token are kept, so a restart doesn't sign users out. The Genesys client is read-only by construction, GET-only with an allowlist of exactly two read-only query submissions, so the app cannot write to Genesys even if asked to. Calls are paced per session at a default 200 requests a minute and four concurrent, an expired token triggers one refresh and retry, and a 429 response honours Retry-After before backing off.

By our count Architect has roughly 150 action types, so we did not try to enumerate them. Flow Journey classifies steps by family and prefix, action, event, menu, started, ended and turn, and gives any member of those families a category, an icon, a readable title and detail extraction, whether or not the app has met that action before. A key outside every family still renders with its full raw detail, badged as unmodelled, and the page lists it, so nothing is silently dropped.

Analysis is the default: an exhaustive, numbered, plain-language report with one section per flow, such as Flow 1 of 2, the inbound flow and its version, with duration, exit reason and badges. Every executed step is an entry with its offset from flow start and how long it lasted. Prompts show the full wording played, with barge-in markers. Menus show the prompt, what the caller pressed, the time to respond and where they were routed. Switches list every option with the one taken ticked; data-table lookups show the lookup value, Found or Not found and every column returned. Reusable tasks nest with dotted numbering, and Copy as text exports the whole report for a ticket or a post-mortem.

Diagram draws the same trace as a top-down node graph. Each flow instance is a titled lane with its type, version, duration and status; each step is a pictorial card with its kind, offset and a one-line detail; and the headline is the keypad chip, showing the digit pressed and the caller's think-time, amber when the pause reads as hesitation. Connectors are labelled with the path actually taken, flow-to-flow hops are dashed, and toolbar controls hide housekeeping steps or show only decisions and input. Click any step and the inspector shows its fields and the untouched raw step JSON, the ground truth one click away.

Four tones run through both views and roll up from step to flow to journey. Red marks an error: an error event handler fired, a flow outcome was set to failure, a step took an error or failure path, the flow exited with an error, or a disconnect ended a flow that never set a success outcome. Amber marks friction: a menu no-match, a caller taking longer than 15 seconds to answer a menu, a lookup that came back Not found, hold music beyond 60 seconds, timeouts, no-input or a truncated trace. Blue marks a handoff, any transfer step, because the IVR did its job and handed the caller on. Everything else is green.

One rule deserves a flow designer's attention. A hang-up can mean a completed self-service call or a caller who gave up, and the trace alone cannot tell them apart. Flow Journey uses the success flow outcome to disambiguate: a disconnect in a flow that set a success outcome is a good hang-up, labelled Completed in IVR; without it the journey reads Caller disconnected. Set flow outcomes in Architect and every diagnostic tool, ours and Genesys's, becomes sharper.

Flow Journey is the single-call lens in a family of QVCCS flow tools. When the question is about thousands of callers, IVR Sankey draws the full-population map and Journey Analyser measures the funnel, and both link back to individual calls. When the question is about the design rather than a call, Flow Mapper renders the published flow and walks a virtual call through it. Flow Journey answers the narrowest, most frequent question of all: what happened on this call, and why.

Two prerequisites live in Genesys, and we say so up front: execution data must be enabled and captured for the flows a call passed through, and Genesys keeps it for 10 days. Values Genesys marks as redacted, such as secure input, render as redacted because the app never receives the cleartext.

The app reflects how our multidisciplinary squads work. Support Engineers and Systems Integration Testers described the questions they answer daily; the Solution Architect set the rule that nothing is ever reconstructed from today's configuration; Senior Developers built it under the Senior Platform Practice Lead's standards, reusing a proven pipeline from our conversation diagnostics, with peer review; and a built-in synthetic demo journey exercises both renderers without credentials, which is how we check the renderer is healthy. Flow Journey is part of the QVCCS App Suite, included with every Managed Professional Services tier.