Skip to main content

​
What is the Routing Audit Log?

The Routing Audit Log is currently in beta, available to selected invites only. If your team is interested in joining the beta, reach out to the Voxworks team.
Every time your assistant acts on a transfer, the routing resolver writes a resolution record: which endpoint it chose, whether that endpoint was open, the destination it resolved to, and how many fallback hops it took to get there. These records are your evidence trail for answering “why did that call go where it went?” A dedicated Audit Log tab under Numbers & Routing is coming soon; until it ships, the 20 most recent resolution records appear in the Recent resolutions section of the Overview tab, which shows the requested route, the resolved destination, and when each transfer happened.

​
When a Record Is Written

A resolution record is written once per transfer that is actually attempted — at the moment the transfer connects or fails. Availability pre-checks (for example, the check that runs before the assistant offers a transfer) do not write records, so the log reflects real transfer attempts rather than background lookups. Logging is deliberately non-blocking: writing the record never delays or interferes with the transfer itself. If a record cannot be written, the transfer still proceeds normally.

​
Resolution Record Fields

The Audit Log presents records as a Resolution log table, most recent first: Behind the visible columns, each record also stores the schedule that made the open/closed decision and the exact routing request, linking the record back to the call, number, and script involved. The log holds the 50 most recent records, displayed 15 at a time — select Load more to reveal the rest. The footer reads “Showing X of Y most recent”. Before any transfer has been attempted, the log shows “No routing resolutions have been logged yet.”

​
CSV Export

Select Export at the top of the Resolution log to download the records as routing-resolutions.csv. The export covers everything the log holds — up to the 50 most recent records, not just the rows currently on screen — with one row per record and these columns: Use the export to reconcile transfer activity against your phone system, or to analyse routing patterns over time in a spreadsheet.

​
Debugging Fallback Transfers

When a transfer’s primary endpoint is closed, the resolver walks its fallback chain and dials the first endpoint that’s open, or runs the closed endpoint’s fallback action — voicemail by default — if none are. The full mechanics, including hop limits and how each fallback action plays out for the caller, are described in Transferring Calls. The audit log tells you which of these paths each transfer took:
  • Depth 0, Status Open — the primary endpoint was open and was dialled directly. Usually nothing to investigate.
  • Depth above 0, Status Open — the primary endpoint was closed and the transfer hopped that many links down the fallback chain before finding an open endpoint. Check the primary endpoint’s schedule if this keeps happening during hours you expect to be staffed — public holidays and date overrides are common culprits.
  • Status Closed — every endpoint in the chain was closed, so no human was dialled and the endpoint’s fallback action ran (voicemail by default). Compare the record’s time against the schedules on the chain, and confirm that’s the experience you want callers to have after hours — see Endpoints.
Keep in mind that Status reflects the schedule decision, not the dial outcome. A record is written whether the transfer connected or failed, so an Open record can still belong to a transfer that rang out or was declined — in that case the assistant speaks its failure message and continues the call. When a caller reports they never reached anyone despite an Open record, the call itself tells the rest of the story. Two companion views help close the loop:
  • The Overview tab flags endpoints that cannot be dialled at all (for example, a team member destination with no number on file) with a banner reading “N endpoint(s) need attention” — fix those before reading too much into their resolution records.
  • The Call Log holds the caller’s side of the story: open the call matching the record’s Call ID to hear how the assistant handled the closed-destination moment.

​
Next Steps

  • Transferring Calls — What the caller and the human agent experience during a transfer
  • Endpoints — Configure destinations, priorities, and schedules
  • Schedules — The business-hours definitions that decide open or closed
  • Call Log — Find the full call behind any resolution record
The Routing Audit Log is in beta, available to selected invites only — contact the Voxworks team if you’d like to join.