> ## Documentation Index > Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt > Use this file to discover all available pages before exploring further. # Routing Audit Log > The resolution records Voxworks writes every time a transfer is attempted — what each field means, how to export them to CSV, and how to debug fallback transfers. ## 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](/routing/endpoints) 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](/routing/overview), 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: | Column | Description | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | When | How long ago the transfer was attempted, as relative time (`45s ago`, `12m ago`, `3h ago`, `2d ago`). Hover to see the exact date and time. | | Call | The call the transfer belongs to, shown as a shortened call ID (for example `#9f3c21ab`). Look the call up in the [Call Log](/calls/history) for the full transcript and outcome. | | Status | An **Open** or **Closed** pill — whether the endpoint the transfer resolved to was open under its schedule at the time. | | Location | The location the transfer requested, or the resolved endpoint's location when none was requested explicitly. Shows "Deleted location" if the location has since been removed. | | Resolved to | The destination the transfer resolved to — a phone number, team member, or SIP address. On a **Closed** record nothing was dialled; the value shows where the transfer would have gone. | | Department | The department the transfer requested (or the resolved endpoint's department), with its icon. | | Depth | How many fallback hops the resolver walked to reach the answering endpoint. `0` means the primary endpoint took the transfer; anything above `0` is highlighted so fallback activity stands out. | 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: | CSV column | Contents | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Time | Full timestamp in ISO 8601 format (UTC), e.g. `2026-07-15T04:12:00.000Z`. | | Call ID | The complete call ID (the on-screen table shows only the first 8 characters). | | Status | `open` or `closed`. | | Location | The location name, or blank. | | Resolved To | The destination the transfer resolved to, or blank. On a closed record, this is where the transfer would have gone — nothing was dialled. | | Department | The department name, or blank. | | Fallback Depth | The number of fallback hops, e.g. `0`. | 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](/routing/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](/routing/schedules) 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](/routing/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](/routing/transferring-calls) — What the caller and the human agent experience during a transfer * [Endpoints](/routing/endpoints) — Configure destinations, priorities, and schedules * [Schedules](/routing/schedules) — The business-hours definitions that decide open or closed * [Call Log](/calls/history) — 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.