As-built evidence in one click: users, phones, queues and groups in a single row

The cut-over is on Saturday. On Thursday afternoon the project manager asks for proof that every agent has a phone that is both allocated and configured as their default station, and the security lead asks which users still hold a supervisor role – including on deactivated accounts. Both answers exist in Genesys Cloud CX. They are simply spread across the People page, stations, phones, sites, phone base settings, queue member lists and group member lists, each in its own admin view.

Config Validator – the As-Built Configuration Validator – was built to answer that question in one click. The server traverses the org's configuration, joins everything into one row per user and streams the run live to the browser. Once the report lands, search, eight filters, sorting and three export formats all happen instantly in the browser, with no further API traffic. The provisioning filter, ‘Allocated + Default’, is the go-live health check the app was built around. Nothing is ever written to the org, and every step of the traversal is visible in a live log.

A report run walks eight stages in order. Users come first, from GET /api/v2/users with expand=authorization,station and state=any, so roles and station links ride along and deactivated and deleted accounts are included on purpose. Then the station inventory from /api/v2/stations, phones from /api/v2/telephony/providers/edges/phones with expand=status, sites, and one phone base settings lookup per unique ID, batched ten at a time, to name each phone type. Queues and their member lists follow, then groups and theirs, and finally the join.

Every list call asks for pages of 200, halving round-trips compared with smaller pages. The join builds lookup maps and assembles a 13-column row for each user: name with department and title, email, state, every profile contact with primaries starred, default phone, roles, queues and groups as pills, assigned phone with a WebRTC badge where relevant, phone type, site, phone status, and two stacked provisioning badges for allocated and default station. Six chips above the table show the raw totals loaded – users, stations, phones, sites, queues and groups.

Connecting a Genesys Cloud user to a phone means traversing three object types, and the validator resolves the chain through three paths in order. The WebRTC path links a station to a user through its WebRTC user ID, and the phone to the station through its first line. The user-station path follows the user's associated station – the one they are logged in to – or their default station, through a phone-by-station index. As a fallback, any station whose associated or default user matches is used.

Two badges then tell the provisioning story. Allocated means a phone record was resolved for the user's station; default station means the resolved station is the user's configured default rather than a transient login association. In the app's terms, an agent who is allocated but not default has a phone that works now but is only an association – exactly what the ‘Allocated, not Default’ filter surfaces before cut-over. ‘Phone, not Allocated’ and ‘No Phone at all’ complete the set, each with the action usually needed.

Phone status is read carefully too. The badge prefers the edge-reported operational status – Operational, Degraded, Failed – and only when the edge reports Unknown or nothing does it fall back to the phone's administrative state of active, inactive or deleted. The Phone Status filter groups these into buckets, plus a synthetic ‘No Phone’ bucket, so a site-by-site review of degraded handsets is a two-click job.

Genesys Cloud CX gives administrators excellent object-level tools. The People page lists each user's name, status, licence, last login, roles, email and division, with filter, search, bulk import, set-state and skills controls. Phones, stations, sites, queues and groups each have their own admin pages for detailed configuration. The bulk import file has a documented column order that includes roles with divisions and queues – and, worth knowing for audits, it adds roles and queues without removing existing ones.

CX as Code goes further for configuration management. Its genesyscloud_tf_export resource exports existing resources into a Terraform JSON configuration file that can be version-controlled, compared and promoted between orgs, and we use it in discovery audits and DevOps pipelines. Terraform describes configuration resources, one resource per object, rather than runtime state such as an edge-reported phone status. Config Validator complements both: a per-user, joined, filterable view of identity, telephony and membership, with runtime phone status, built for reviewers, auditors and handover packs rather than for applying change.

Small orgs finish in seconds; large orgs take several minutes, because calls are deliberately paced. Every Genesys call in a session flows through an adaptive pacer that enforces a minimum spacing – 250 ms, roughly four requests per second – even when several fetchers run in parallel. Each HTTP 429 multiplies the spacing by 1.5, up to two seconds, and the Retry-After header Genesys returns is honoured with random jitter. After 30 consecutive successes the pacer eases back towards baseline, so one brief throttle does not slow the whole run.

Membership is where real orgs bite. Queue member lists are fetched eight at a time, but group member lists only two at a time, because in our testing the group members endpoint answered bursts of nine parallel calls with 429s carrying a 60-second Retry-After. Each membership fetch is capped at 90 seconds so one huge dynamic group cannot stall the stream. A failure is logged as a warning and the report still completes; a missing permission simply leaves the affected columns empty.

Progress, the API Communications Log and the finished report all arrive over one Server-Sent Events stream. The terminal-style log shows a timestamped line per page fetched with running totals, pacing changes and warnings, and stays open after completion so the full API trace can be reviewed next to the data – useful evidence in its own right when an auditor asks how the report was produced.

Once the report lands, free-text search matches names, emails, departments, titles, every contact string with its media-type and primary tags, role names, and phone name, type and site. Queue and group names have dedicated dropdowns. Eight filters combine instantly: state, phone presence, role, queue, group, site, phone status and provisioning. Want every active agent in the Leeds site who is allocated but not on their default station? That is three dropdowns, and the result counter shows filtered against total users. Deactivated and deleted users can be hidden with the State filter, or kept in view for a role review.

Exports contain exactly the filtered rows at the moment you click and are generated entirely in the browser. CSV and XLSX carry 20 columns, from first and last name to allocated and default station, with multi-value fields joined by a pipe; the PDF is a landscape A4 layout with a timestamp and page numbers for the handover pack. The application only ever issues GET requests against the Genesys API, plus the one token request needed to sign in, and no report data is stored server-side – it lives only in your browser tab.

Config Validator earns its keep at three quality gates. In Discover, it is part of our existing-org configuration audit alongside a CX as Code export. In Build, it gives the four-eyes peer review a configuration audit against the Low-Level Design: every user, every phone, every membership. In Transition, its exports go straight into the operational handover pack as as-built documentation, and the provisioning filter becomes the last check before the go / no-go readiness decision.

The app is part of the QVCCS App Suite included with every Managed Professional Services tier. The squad who use it on your org are mustered from our own bench: a Solution Architect owning the design authority view, IT Systems, Telecoms and SIP Engineers for stations, phones and sites, Systems Integration Testers who trace findings back to the Requirements Traceability Matrix, and support engineers who keep the evidence current in run and evolve – backed by the whole practice.