Why 3CX routing is hard to reason about

On paper, a 3CX inbound call is simple: a number rings, and someone answers. In practice, the path from "the carrier delivered a call" to "a phone rang on a desk" threads through a half-dozen configuration objects, each living on its own page of the Management Console:

• A trunk (or SBC, or bridge) accepts the call from the carrier.
• A DID — the specific phone number that was dialled — is matched.
• An inbound rule decides where that number goes, and it branches three ways: one destination for office hours, one for after hours, one for holidays.
• That destination might be a digital receptionist (IVR), whose menu fans out again — "Press 1" to sales, "Press 2" to support, a timeout to an operator, an invalid key back to the top.
• A menu option might land on a ring group (ring everyone at once) or a queue (hold callers and distribute to agents).
• Only then does it reach a user, or fall through to voicemail, an external number, or a fax.

Every one of those objects is configured on a different screen. The console will happily tell you what a single inbound rule does, or which agents are in a queue — but it never draws the path. To answer a question as basic as "what happens when someone calls the main number at 9pm on a holiday?" you have to open the inbound rule, read the holiday branch, follow it to a receptionist, open that receptionist, trace the timeout forward, open the ring group it points at, and check who's in it. Hold all of that in your head, then do it again for the next number.

This is fine when you built the system last week. It's painful when you inherited it, when the person who built it has left, or when you manage twenty of these for twenty different customers and none of them are documented.

How a visual map helps

The Call Flow Visualizer reads the routing configuration straight from 3CX — trunks, DIDs, inbound rules, IVRs, ring groups, queues, users, groups, and the holiday table — and lays the whole thing out automatically, left-to-right, the way the call actually travels. You don't draw anything. Open the tab and the map is already there.

Two design choices make it readable at a glance. First, every node is colour- and icon-coded by type: trunks, DIDs, IVRs, ring groups, queues, users, voicemail, external, and fax each get a distinct colour and icon, with a legend. You can tell a queue from a ring group without reading a word. Second, every edge is labelled by the condition that follows it. A connection isn't just "this goes to that" — it's tagged office hours, after hours, holiday, a keypress like "Press 1," a timeout, or a no-answer hand-off, each in its own colour. The picture tells you not just where calls go, but when and why.

On top of that there are a few controls that turn a busy diagram into exactly the view you want:

• Time-of-day filter

  Flip between All, Office Hours, After Hours, and Holidays to see only the routing that's active in that mode. It opens on whatever mode the PBX reports it's in right now.
• Type filters

  Show only the entity types you care about — users, DIDs, IVRs, ring groups, queues. Hiding trunks even splices the incoming number straight to where it actually routes.
• Hide orphans

  Drop any node that has no connections in the current view, so the canvas stays focused on the live path instead of unused leftovers.
• Search to highlight

  Type a name, number, or type and the matching nodes light up while everything else dims — handy for finding one extension in a dense map.
• Expand groups on demand

  Ring groups and queues stay collapsed by default; click one to reveal its members. Fans of numbers that share a destination collapse into a single tidy node too.

1. Onboarding a new PBX (or a new engineer)

The fastest way to understand an unfamiliar 3CX is to look at its call flow, not to read its config page by page. When you take over a customer from another provider — or hand an instance to a new technician — the diagram is an instant orientation: here are the numbers, here's the after-hours path, here's the queue that handles support. What used to be a half-day of clicking is a single screen.

2. Auditing routing for mistakes

Misconfigured routing is quiet until it isn't. A holiday branch that still points at last year's destination, a DID that drops a caller into a dead extension, an after-hours rule that rings a desk that's empty all night — these don't throw errors; they just lose calls. Seeing every branch drawn and labelled makes the gaps obvious. The time-of-day filter is built for exactly this: flip to After Hours or Holidays and confirm, in one look, that callers land somewhere sensible.

3. Troubleshooting "where did my call go?"

When a customer says "people calling our main line get a busy signal after 5," you can either reconstruct the path by hand across six console pages, or you can open the map, switch to After Hours, and follow the one highlighted route. The diagram turns a tracing exercise into a reading exercise — and because it's pulled fresh from the live configuration, it shows what's actually deployed, not what someone thinks is deployed.

4. Client documentation that stays honest

Hand-drawn call-flow diagrams in a Visio file or a slide deck are out of date the moment someone changes a rule. Because this map is generated from the live config every time, it never drifts. Export it and you have routing documentation a client can actually read — for a quarterly business review, an onboarding packet, or just answering "remind me how our phones are set up?"

Putting the export to work

The diagram exports two ways, each suited to a different job. PNG comes out at 2× resolution — sharp enough to paste into a support ticket, a Slack thread, or a slide without looking fuzzy. SVG is the one to reach for when the diagram matters: it's a true vector, so it stays crisp at any zoom, and opening it in a browser and printing to PDF gives you a clean, scalable document for a runbook or a client deliverable.

There's a third path that's easy to miss: the same diagram can be embedded on a customer's status page. Pair it with a white-label customer status page and a client gets a read-only window into how their own phone system is wired — health, uptime, and call flow — without a login and without any ability to change a thing. For an MSP, that's a documentation deliverable and a support deflector in one.

The read-only guarantee

It's worth being explicit, because it's a deliberate design decision rather than a missing feature: the Call Flow Visualizer never writes to your PBX. It reads the configuration and draws it. You cannot drag a node to re-route a call, you cannot add or delete a rule, and there is no "apply" button hiding anywhere. Every routing change still happens in 3CX itself, through the normal Management Console, with the normal permissions and the normal audit trail.

That constraint is a feature for the people who'll use this most. You can safely hand the diagram — or a status page that embeds it — to a junior tech or a customer, knowing the worst they can do is look. The tool's whole job is to make a complicated system legible, and legibility is most useful precisely when you don't want the viewer touching anything.

How Sikurd fits in

The Call Flow Visualizer is one tool inside Sikurd, the platform MSPs use to monitor, manage, and back up every 3CX server in their fleet. Because Sikurd is already connected to each instance, there's no separate setup to map a call flow — open any customer's PBX and the diagram is one click away, generated on demand from the live configuration. No agent on the box, no firewall changes, no exported config files to wrangle.

If you manage more than a handful of 3CX servers, the value compounds: routing documentation for any customer, current as of right now, ready to read or export, without it ever being a project. See how Sikurd compares for managing multiple 3CX servers for the wider picture.