Where does every number go? Auditing Genesys Cloud DIDs, flows and caller IDs

It is 08:55 on a Monday and the team leader on the sales floor has a puzzle. A customer says they dialled the new promotions number and reached a recorded greeting for a service line that was retired last year. Another caller swears their own mobile rang moments after they hung up, showing their own number. Meanwhile one agent keeps receiving calls that should have gone to a queue. Three symptoms, one root cause: nobody can say, with confidence, where every number in the org actually goes.

In Genesys Cloud CX, a phone number is not one record in one place. It can sit in a DID range, be assigned to a person, a phone or a call flow, appear in a call route alongside its open, closed and holiday flows, live in a site number plan or a trunk’s inbound routing, be typed into a user’s profile as a work or mobile number, and be used as the caller ID on an outbound campaign. Each of those places is correct on its own terms. The trouble starts when they disagree – and spotting that means reading them all at once.

Genesys gives administrators good tools for each object. The Call Routing page under Admin > Routing lists each call route with its open call flow, closed call flow, holiday call flow, schedule group, emergency settings, division and inbound phone numbers. When a caller dials one of those numbers, they are routed into the associated inbound call flow. The DID Numbers page under Admin > Telephony splits into DID Ranges, where purchased numbers are made available, and DID Assignments, where each number can be assigned to a person, a phone or a call flow, with Assignee and Type columns and an Assigned or Unassigned view. Orgs on Genesys Cloud Voice administer numbers through Number Management instead.

Outbound is configured somewhere else again. Every dialler campaign carries a caller ID phone number and name – the callerAddress and callerName fields in the API – which is what the person you are calling sees. User profiles carry their own contact numbers in addresses and primary contact information. None of this is a gap in the platform; it is the natural shape of a system where routing, telephony, people and campaigns are administered by different teams with different permissions.

The insight behind our app was simple: the questions that hurt are cross-object questions. Does any agent’s profile number collide with an inbound DID? Is any number registered to two different flows? Is any inbound DID also being presented as an outbound caller ID? Answering those from the admin pages means exporting, copying and VLOOKUP-ing across several screens. So we built a single view that joins them – the figure below shows the Genesys data model it reads and how every source converges on one number registry.

In the app – which appears in-app as the QVCCS DID Validator, and which our team calls DIDmapper – a single Run Audit click walks the org in a fixed pipeline. It loads every inbound call flow from /api/v2/flows?type=INBOUNDCALL&deleted=false, then every IVR configuration from /api/v2/architect/ivrs. Each IVR resolves to a flow from the first of its open-hours, default, closed-hours or holiday flow references, and every number in its dnis list is registered against that flow. This is the canonical DID-to-flow bridge, and it is why the call route is the first thing we read.

Four further sources follow. Source A is the individual DID records from /api/v2/telephony/providers/edges/dids, resolved in three passes: through the IVR map when ownerType is IVR_CONFIG, directly when the owner is an inbound-flow id, and by type hints otherwise. Unmatched numbers are kept as Unassigned so they still take part in the agent check, and an ownerType census explains at a glance why nothing mapped – if every DID is owned by USER, there are simply no flow assignments to find. Source B registers DID pool start and end boundaries. Source C fetches every site’s number plans. Source D reads inbound routing embedded on trunks.

Real orgs are messy, so a records-agnostic resolver tries every field shape we have met – owner, routing target, flow, inbound route, call route, destination – covering Genesys Cloud Voice, BYOC and older configurations. Numbers are normalised to digits with a leading plus, and the whole run streams into a live scan log stage by stage, with per-page pagination progress on large orgs, so nobody stares at a spinner wondering whether anything is happening.

The agent conflict check harvests numbers from the addresses, primary contact information and phones of every active user via /api/v2/users, then compares each against every registered number, mapped or unassigned. Two numbers conflict when they are equal or when their last ten digits match, so +1 702-555-0142 and 17025550142 collide as intended, while short extensions only ever match exactly. Each flagged agent gets a card naming the exact profile field at fault – addresses › WORK, for example – with the clashing DID and its flow, plus a flat summary table ready to paste into a ticket.

Duplicate routings are numbers registered to two or more distinct flows. Only one assignment can win, so the others are dead configuration that someone will one day trust. The subtle part is provenance overlap: when a call route and a DID record both point the same number at the same flow, that is expected, and the app deliberately does not count it. A duplicate always means two different flows, listed with the source of each registration so the fix is obvious.

The third check is the one that makes customers ring back angry. We call it the ghost ring: a number that is both an inbound DID and an outbound campaign callerAddress. The audit reads /api/v2/outbound/campaigns, compares every caller ID with the full inbound set, and flags each collision with the campaign name, the inbound flow and an Active or Off pill. Campaigns that take their caller ID from the contact list have no callerAddress, and our user guide says plainly that those cannot be checked this way.

Findings are only half the value; the inventory is the other half. The results workspace lists every inbound flow with its numbers as chips, sorted by E.164 with a country flag, national digit grouping and a source pill such as DID, DID Pool, Site or Trunk. Flow names deep-link straight into Architect. A reverse name filter hides every staging flow in one keystroke, a digits-only search finds a number across all flows, and the sort can put oldest-published or no-DID flows first.

Two chips turn the inventory into a clean-up plan. A staleness chip appears when a flow’s last publish is 180 days or more ago, and the “only flows with no DID” toggle shows orphans. Combine them and you have a decommission-candidate list that a design authority can actually review. An optional second pass inventories the eleven non-voice flow types – chat, email, message, secure call, bot, workflow, in-queue, outbound and survey – for a complete Architect catalogue.

Everything exports in the browser: four CSV files, a five-sheet Excel workbook including the ownerType census, or a branded landscape PDF with an executive summary that suits audit hand-over. Exports honour the on-screen flow filter and stamp it into the file name, while conflicts, duplicates and caller-ID findings always export in full, because they are a separate concern from whatever you were browsing.

An audit tool that can change routing is a liability, so this one cannot. Apart from the OAuth client-credentials token call, every request it makes is a GET. It needs a read-only role covering telephony, Architect, routing and the user directory, with outbound read as an optional extra for the caller-ID check. The client secret is sent once at sign-in and never returned to the browser, a fresh token is fetched for every run, and results are never stored server-side – they live in the browser tab until the next audit. Because results contain agent names and numbers, the guide reminds users to treat exports accordingly.

We built it the way we deliver any change. Our IT Systems, Telecoms & SIP Engineer defined the number sources from real Genesys Cloud Voice and BYOC estates; a Senior Developer built the resolver and pipeline; and a Systems Integration Tester ran negative and failure-path tests against missing scopes, empty sources and odd field shapes, with Practice Lead peer review before release. It earns its keep in the Transition stage of our method – rehearsing a number porting plan or a cut-over – and again in Run & evolve health checks, backed by the whole practice.