Flow Narrator: a plain-English as-built of every journey through your Architect flows

It is handover week for a new inbound service. The operations manager asks a question that sounds simple: if a caller rings after 18:00, presses 2 for billing and the CRM lookup times out, what happens to them? The flow engineer knows the answer is in Architect, spread across an inbound call flow, a common module, a data action, a schedule group and an in-queue flow. Showing the manager means a screen-share and a lot of clicking, and the next person to ask will need the same tour.

Contact centres run on flows that only their authors can read. Business owners sign off journeys they have never seen written down, auditors ask where a data action sends customer data, and support engineers inherit flows built three versions ago. What everyone needs is the as-built in words: what the caller hears and can do at each step, what the system checks and why, what each integration is asked and how its answer changes the call, and every way the call can end.

Architect is a capable authoring tool, and Genesys gives flow engineers good ways to move and inspect configuration. Any flow can be exported from its Save menu, either in Architect's own configuration format or in YAML, optionally with tracking IDs, and Archy, Genesys's YAML processor, lets teams create, check in and publish flows from YAML in automated environments. Within a flow, the Dependencies pane lists the queues, users, skills, scripts, prompts and other resources it uses, with links to every usage, and Find consuming flows shows which flows call a common module, bot, in-queue or secure call flow.

Across the organisation, the Dependency Search tab finds the published and checked-in flows that contain a particular resource. These tools serve engineers well, because they speak the language of the configuration: actions, expressions and ids. Flow Narrator speaks the language of the caller and the business. It does not edit or replace anything in Architect; it reads what is there and explains it, for people who will never open Architect, and for engineers who want a reviewable record of a specific version.

A caller's journey is not one flow. It is the starting flow plus the bots it calls, the common modules it runs, the flows it transfers to, the in-queue flows of the queues it sends callers to, and the post-call workflows a trigger ties to it. Flow Narrator follows only what the starting flow calls or refers to, and what those call in turn. It never reads other flows just because they exist: a flow the caller cannot reach is not part of the story. After signing in, you see every flow in the organisation, of every type, with its division and published version; the list opens on inbound call flows, where most journeys start, and searches by name, description and division.

Versions are handled precisely. You choose the version to describe, the published one by default or any other saved version, shown with who created it and when, with debug versions marked. Every flow it calls is read at the version Genesys runs: the version a Call Common Module or Call Bot Flow block pins, otherwise the published version, and if two blocks want different versions of the same flow, the document says which it describes. If you chose an unpublished version, the document says so, because call routes and post-call workflows reach only the published one. Where a transfer goes to a queue held in a variable, for example one looked up in a data table, the in-queue flow cannot be resolved from configuration, so the document lists the transfer in its Scope appendix rather than guessing.

Post-call workflows are included only on an exact match: a process automation trigger whose condition values are exactly the id or name of something in the journey, or the dialled numbers the call routes send to the flow, which is the most common way a trigger is tied to a flow, or a trigger that runs after every conversation with no conditions. A partial match never counts, so Sales does not match Sales Europe, and the inventory says which trigger included each workflow and why, for example that it matches 14 of its 14 dialled numbers.

Flow Narrator signs in with an OAuth client-credentials grant whose role holds read permissions in the divisions being described. The secret is held encrypted on the server, never sent to the browser and never shown again. Every call it makes is a GET; anything else is refused inside the application before it reaches the network. The guide lists each read with its role permission and OAuth scope, from Architect › Flow › View with architect:readonly to Process Automation › Trigger › View with process-automation:readonly, and every row was checked against the permissions and scopes Genesys publishes in its own API definition. The same list is printed in every generated document.

When the client cannot read something a flow refers to, such as a bot it cannot open or a hidden data action definition, the gap is recorded in Genesys's own words, with the permission it names, and the document says what that gap prevents it from describing. Every endpoint was read successfully against a live organisation during the build, and the one refusal we met, for process automation triggers from a client whose role lacked processautomation:trigger:view, is shown exactly that way. The trawl, with a progress bar and a running log, then produces a saved inventory: the call routes and numbers that reach the flow, each flow with its version, publisher and exactly where it is reached from, every data action with the integration, method and host it calls, data tables with their columns and row counts, schedule groups with their time zones, prompts with their languages and missing transcripts, and every Genesys endpoint read.

Review the model shows the steps Architect will run, built in a fraction of a second to Architect's own structure: each branching block opens one branch per outcome, and when a branch runs out the flow carries on after that block. Jumps never return, so after Jump to Reusable Task, Jump to Menu, End Task, Loop Next or Exit Loop nothing below runs; Call Reusable Task, by contrast, runs the task and carries on. Blocks after a transfer appear under its If the transfer fails branch, blocks after a block whose every branch leaves are listed as can never run, and a task or menu nothing leads to is marked never runs and kept out of the journey. The rule is confirmed on real call traces: a block that ran on every call up to version 69 of one production flow has not run once since a jump was placed in front of it in version 70.

Conditions are translated from Architect's parsed expression tree, not its text, with brackets exactly where Architect groups them and zero-based positions turned into words, so Flow.ids[0] reads as the first item of ids and Substring(Flow.x, 6, 2) as the two characters starting at the seventh. Recorded prompts appear with their transcript or are marked no transcript, and in a multi-language flow the default language's transcript is shown with every language's in the Prompts appendix. Anything that cannot be translated is quoted exactly and counted on the Checks tab, alongside the model's views of tasks and menus, data actions, where calls end, and variables never set or never read.

Read the document writes the narrative fresh each time, titled with the flow and version, dated and time-stamped in UTC and citing Quo Vadis CCS Ltd as its generator. Every chapter and every task opens with a summary written only from facts in the model, counts, names and connections, never guesses, so managers and project managers can read the summaries while flow engineers read the detail. Front matter carries the flow, version, organisation, generation and read times, and a disclaimer setting out what the document can and cannot say and how permissions affect it, followed by an executive summary with an at-a-glance table.

The body covers how calls arrive, with call routes and numbers, schedules written out in words such as every Monday to Friday, 07:30 to 16:00, past dates flagged, standalone schedule checks with their time zone, languages, voices and what happens on a system error; the caller's journey task by task, every step numbered with its tracking id; one chapter each for bots, modules, transferred-to flows, in-queue flows and post-call workflows; every data action grouped by integration, with what is sent, where each answer is stored, which steps read it and what happens on failure or timeout; every ending with the conditions that lead there, including those implied by earlier branches; and flow outcomes and milestones, with whether each can end as a failure. Appendices hold design observations, the parts that never run, gaps, prompts and recordings without transcripts, participant data written, data tables, variables, scope, permissions with every Genesys call made, and a block index.

Word and PDF are produced together from the same document shown on screen, so they always agree, and a flow of a few hundred pages takes well under a minute. A coverage check counts the blocks that can run and refuses both files unless every one is described, and the server checks again before writing. The files are A4, with Arial in Word and, in the PDF, Liberation Sans, which has exactly Arial's character widths so every line breaks in the same place, royal-blue chapter bars, summary boxes and header rows that repeat across pages; every page carries the title, the organisation, the UTC generation time, the generator and Page n of m. Contents carry page numbers and links, every numbered heading is a bookmark, the block index links each tracking id to its section, the PDF carries a bookmark panel, and step numbering is written into the text so it can never drift from the tracking ids.

Because the model knows every path, it also knows what is never used. The appendices list blocks that can never run and why, tasks and menus nothing leads to, data action answers stored but never read, variables read but never set and schedules already in the past. For a flow owner these are the quiet defects that survive every release, and they arrive as a list with tracking ids rather than as a hunch. Unreachable tasks and menus are still described in full, in their own appendix, so nothing in the configuration goes unaccounted for.

Flow Narrator keeps only what it needs. Saved flow readings, Word and PDF exports and signed-in sessions are held for the OAuth client that produced them, and the Stored data page shows exactly what is held for that client and nothing of any other. Anyone who can sign in with the client can delete a reading, with its files, or an export on its own, sign out the other sessions, or delete everything after typing the organisation's name to confirm. Deletion waits while a flow is being read or an export produced, cannot be undone, and nothing else about the organisation is kept. Every build step is complete, from sign-in, the trawl and the model to the writer, the Word and PDF document and proof against three differently built flows.

Flow Narrator grew out of the QVCCS method, where the Transition stage closes with an operational handover pack that includes as-built documentation. Our Senior Business Consultant defined who reads an as-built and what each reader needs; the Solution Architect designed the model to mirror Architect's own execution rules; Senior Developers built the trawl, the translator and the writer under the Senior Platform Practice Lead's engineering standards; and our Systems Integration Tester read every endpoint against a live organisation during the build and proved the finished tool on three differently built flows. It is the same multidisciplinary squad, mustered from our own bench, that builds and supports client flows.

For clients, the result is documentation that keeps up with the platform. Business owners can sign off a journey they have actually read. Auditors can see where every data action sends data and what comes back. Support engineers get a version-specific record with tracking ids that lead straight to the block in Architect. And because the document is regenerated from the live configuration on demand, with new files and a new generation time whenever the flow is read again, the as-built is no longer a deliverable that goes stale the week after go-live.