Flow Mapper: see every Architect flow whole, audit it, and document it as built

A design review is booked for Thursday. The client's new Head of Contact Centre wants to see what the IVR actually does, the operations team wants to know which queues it can send callers to, and an auditor has asked for a point-in-time record of the configuration. The organisation has dozens of flows, common modules called from several of them, data tables that drive routing, and participant data written by flows that three different teams have touched over the years.

Everyone in the room can open Architect. Few want to click through nested tasks and action panels on a projector, and nobody wants to assemble the as-built by hand from screenshots. We built Flow Mapper, called Flowmapper inside the app, to make the configuration legible: one place to see a flow whole, walk a call, check every reference against what really exists in the organisation, and hand over a document that matches the build.

Architect is an editor, and a good one. You open a flow, work on its tasks, menus and actions, then check it in and publish it. Two native features answer the where-is-this-used question. Under Resources, the Dependencies pane lists every resource the flow uses, with its type and links to each usage. And the Dependency Search tab on the Architect home page lists the flows that contain a particular resource, across more than 25 dependency types including queues, data actions, data tables, user prompts, schedules and scripts. Find consuming flows does the reverse for common modules, bots, in-queue and secure call flows.

Genesys documents the scope of Dependency Search carefully: it applies to checked-in and published flows, and it does not include prompts fetched through an expression, because those are evaluated only at runtime. It is a search for a resource you can name. What clients asked us for sat alongside it: the whole flow on one canvas with prompt wording and queue targets in place, references that do not resolve to anything, names that nearly match, the same attribute spelt two ways in different flows, and a document they can sign off.

Every Architect flow version is stored as configuration that the Platform API returns as JSON. Flow Mapper does not use the Architect Scripting SDK to draw diagrams. The server reads the flow, chooses the published version, falling back to checked-in and then saved for a flow that has never been published, and fetches that version's configuration over REST, following a configuration link where Genesys provides one, still authenticated and still a GET.

The configuration is parsed locally into a normalised flow model: lookup tables from the UI metadata, a start node, task and menu containers with their action chains, edges wired from each action's next action and output paths, jump edges for call-task, transfer and menu-choice targets, loop back-edges, synthetic end nodes wherever a chain falls through as Architect does at runtime, return edges from task ends to their callers, and finally the variables and a manifest that catches references a per-action walk would miss. Two enrichment passes then run against the organisation's inventory: prompt tokens in communicate expressions resolve to per-language text and audio, and transfer targets resolve to real queue records. A name that matches nothing is stamped unresolved, and the diagram paints it red.

Flows lists every Architect flow the OAuth client can see across all 17 REST-listable flow types, from inbound call and bot flows to workflows, common modules, surveys and voicemail, with division, published version and publish date, a search box and an exclude box for hiding staging or test flows. Open one and the diagram fills the screen. Containers stack in call order; within each, actions are ranked into layers and the happy path is pinned to a straight centre column, so the primary story reads top to bottom while error branches hang off the sides. Edge crossings render as small bridge hops so lines never read as merged.

Multi-output actions show port chips, Success, Failure, Timeout or case labels, so every branch is visible at a glance, and an unresolvable queue name is flagged in red on the node before any audit runs. Click a node and the inspector shows its full configuration: prompt wording per language, pretty-printed expressions, data action input and output contracts, queue records with members, division and wrap-up codes, and every incoming and outgoing edge as a clickable jump. A raw JSON download gives the exact Architect configuration for diffing or archiving.

From the inspector, the Walker steps through the flow like a virtual call. At each junction it offers the outgoing branches as buttons, Yes or No, case values, Success or Failure, menu choices, and as it lands on communicate nodes it builds a caller-facing transcript of the text-to-speech or prompt content, with inline players for recorded audio. Reusable tasks offer return-to-caller branches, so round trips read naturally. In a design review, that is how we narrate a call path without touching Architect.

Press Run audit and an organisation-wide sweep streams live: the inventory of queues, data tables with their schemas, data actions, user prompts and all flows is loaded, every flow is parsed with the same parser the diagrams use, and findings arrive grouped by severity while a progress log scrolls. Tier one checks direct references: every queue, data table, data action, prompt and target flow in every flow must resolve, by id, then exact name, then ignoring case. Nothing matching is a High broken reference; a close match is a Medium typo suggestion; a match that differs only by case is a High case mismatch.

Tier two reads inside the data tables that so often drive routing: every cell is checked against the queue, data action, prompt and flow inventories, and near-misses are flagged as likely typos, scanning up to 2,000 rows per table. Tier three looks for drift across the whole organisation: participant-data attribute names and flow variable names are gathered from every flow, and groups that differ only by case or sit within one or two edits of each other surface as clusters. That is the classic Task.IsBlocked versus Task.isBlocked problem, where two teams wrote the same idea two ways and a downstream report, data action or screen pop reads only one of them.

Tier four attaches to every unresolved reference the closest inventory match by edit distance, with the distance shown. Dynamic references, expressions that build a queue name or read a variable at runtime, are deliberately skipped, because they cannot be validated statically and are not typos. Every finding carries its severity, category, the referencing flow and node or table and cell, the attempted name and any suggestion, and a deep link that opens the flow with the offending node focused and flashing. Findings export to CSV for the change backlog.

Around the diagrams sit inventory pages for prompts with per-language text and playable audio, data tables with schema and rows, data actions with their input, success and failure contracts, integrations with the actions each provides, and queues with skill evaluation method, calling-party settings and wrap-up codes. Twenty-odd further inventories, from users, groups and skills to schedules, divisions, telephony, outbound, quality, workforce management, knowledge, recording policies and canned responses, are read through the Platform API for the as-built document.

The As-Built page configures a generation job: executive scope for totals and a section map, standard scope as the recommended handover set with personal data redacted and data-table rows capped, or full scope, unredacted with all rows, for controlled environments only. A section picker adds or removes any section; including the audit runs a full sweep inside the generation, and its findings become the document's configuration-health appendix. With diagrams included, a headless browser captures each flow's own diagram for embedding, and a per-flow failure simply omits that image rather than failing the run.

Generation runs as a detached server-side job, so a page reload re-attaches to it, and the finished Word document is held only in memory behind a one-time download for about 30 minutes. Redaction masks email addresses, international phone numbers and long digit runs in section bodies and table rows, while deliberately leaving identifiers that are structural cross-references. In the QVCCS method, that document is part of the operational handover pack at Transition, generated from the live configuration rather than typed from memory.

Flow Mapper cannot modify, publish, check out or delete anything. Its shared Genesys client refuses any request other than a GET before it leaves the server, so the guarantee is enforced in one place rather than feature by feature. It signs in with an OAuth client-credentials grant, keeps the client secret encrypted, never sends a Genesys token to the browser, stores no organisation configuration data at rest (only an encrypted sign-in credential and token are kept, so a restart doesn't sign users out), and paces every session at 200 requests a minute with retries that honour Retry-After. Read-only role bundles cover everything it reads, and each inventory page degrades on its own with the missing permission named.

It is the design-time member of a family of QVCCS flow tools. Flow Mapper shows what the flow can do; Flow Journey shows what it did on one call; IVR Sankey shows what it did for every caller in a window; and Journey Analyser measures the paths that matter as funnels. We designed it for the moments our multidisciplinary squads meet the configuration: the Solution Architect's design authority review, the Senior Developer's four-eyes peer review, the Systems Integration Tester's path-by-path test design and the Trainer's handover session. It is part of the QVCCS App Suite, included with every Managed Professional Services tier, and backed by the whole practice.