Route Analysis

Route Analysis answers the questions that come up whenever inbound routing does not behave the way you expect: where would this call actually go, when does the answer change, what is misconfigured, and what else depends on the object I am about to edit.

Where the Call Flow Diagram draws the shape of a route, Route Analysis evaluates it. It picks a moment in time, applies the schedules, modes, and routing conditions that are in effect at that moment, and reports the destination the caller would reach.

The screen has four tabs. They share the number you are working on, so you can move between them without retyping it.

Simulate

Enter a DID and click Run to see how a call to that number would route.

• Date and Time is optional. Leave it empty to route as of now, or pick a moment to ask “where does this call go at 7pm on Saturday?” The moment is interpreted in the tenant timezone.
• Caller ID is optional. Supply a calling number to test Routing Conditions that match on caller ID.

The result shows which routing option won, which options were considered and rejected and why, the schedule or Mode that decided the outcome, and the final destination.

Week

A week-long sweep of a single DID. The result is a grid of the whole week, so changeovers between daytime and after-hours handling appear as visible boundaries, and any period with no coverage stands out as a gap.

Leave Week Of empty for the current week, or enter any date inside the week you want to inspect.

Use this after a schedule change to confirm the transitions land where you intended, and to find the hours nobody thought about - typically holidays, weekend mornings, and the minutes either side of a business-hours boundary.

Audit

Scans routing for problems rather than answering a question about one number. It reports:

• Routes whose destination is missing or no longer exists
• Routing loops, where a path returns to a point it already passed through
• Times of the week that no option covers
• Shadowed options - rules that can never be reached because an earlier rule always matches first

Calls enter the system two ways, and both are audited. An outside caller arrives on an inbound number. Someone inside the organization dials a feature code - a short number such as 611 or *85 that sends the call to a voice menu, a hunt group, a mailbox or a paging list. A feature code is not reachable from outside, so a problem behind one is invisible to any check that starts from a number, and it fails every time somebody presses it.

The Object column says which of the two a finding came from: the number, or the code with (dialed) after it.

Feature code findings show not time based in the Exposure column. Exposure is the share of the week a problem is on the path of an incoming call, and a feature code has no share of one - it is available at all times to anyone with a handset. Those findings are reported at a fixed severity instead, which is why a broken feature code ranks below a number that answers nowhere even though both are always broken.

Scope selects what is audited. Tenant administrators audit the current organization. System administrators can also select All Organizations to audit the whole system in one pass.

Where Used

Before you change or delete a shared object, check what depends on it. Choose the object type, enter its name, and Run. Ten types can be looked up: Extension, Queue, Hunt Group, Voice Menu, Conference, Voicemail, Schedule, Office Mode, Routing Condition and Feature Code.

The result lists everything that references the object and what would break if it were removed. Run this first on anything shared between several routes.

A feature code is the exception to how the result reads. Nothing in the configuration can reference one, because it is dialed on a phone rather than routed to, so the reference list for a feature code is always empty. That is not a sign it is unused, and Where Used says so: a feature code is always reported as Breaking to remove, because deleting it takes the code away from everyone who dials it. Whether anyone still dials it is not something the configuration records; check with the people who use it before removing one.

A Typical Investigation

1. Audit turns up a route with an uncovered period.
2. Simulate that DID at a time inside the gap to watch the call fall through to the default.
3. Where Used on the schedule involved, to see which other routes would be affected by fixing it.
4. Make the change in Inbound Routes, then re-run Week to confirm the gap is closed and nothing else moved.

Opening Route Analysis

Two ways in:

• Tools > Route Analysis opens the screen with nothing filled in.
• The Simulate Route button on the Inbound Routes grid opens it on the Simulate tab with the selected DID already entered. Select a single route first; the tenant default route cannot be simulated on its own because it has no number of its own.

Notes

Route Analysis is read-only. It never changes configuration - it reports on what is already there, so it is safe to run at any time, including on a production system during business hours.

Results reflect the configuration as saved, not as deployed. If you have pending changes that have not yet been applied to the call processing servers, the analysis describes what will happen after they are applied.

When you change the selected organization in the Configuration Manager toolbar, Route Analysis reloads that organization’s DID list, clears prior results, and drops cached object pickers so you never keep analyzing the previous organization by mistake.