> For the complete documentation index, see [llms.txt](https://help.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.distro.so/reporting/routing-logs.md).

# Routing Logs

Use Routing Logs to understand what happened to a particular prospect. They bring together the recorded routing decision, assignment, booking, and related activity. Workspace admins can inspect logs for their workspace.

## Find an attempt

Open **Form routing → Routing Logs**, **Click routing → Routing Logs**, or **Outbound routing → Routing Logs**. Search for the prospect and narrow the results with the filters available on that page.

You can also follow a routing-log link from a router, booking, or insight report. Open the row to review its details.

| Routing type         | One row represents                                                      |
| -------------------- | ----------------------------------------------------------------------- |
| **Form routing**     | A recorded form submission and its routing context.                     |
| **Click routing**    | A recorded routed visit and its result.                                 |
| **Outbound routing** | A sales handoff, which can contain several routing or booking attempts. |

## Follow the recorded result

For Form and Click Routers, review the submitted values, rule evaluation, assignment, and meeting details. CRM activity and workflow results appear separately. A successful routing decision can still be followed by a failed CRM update or workflow action.

<figure><img src="https://2442454418-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FQA3GQNrIYVrPQ90NBwRa%2Fuploads%2FUb5o83QlUbQ3R967DuSU%2Fdistro-routing-timeline.jpg?alt=media" alt="Routing timeline with an expanded rule match, assigned owner, and completed meeting outcome"><figcaption><p>Expand a routing decision to see the rule and recorded values behind the match.</p></figcaption></figure>

A **Booked** result means a booking exists. Open the meeting details to check whether it was later cancelled or marked as a no-show. The current booking owner can differ from the original assignment; use the recorded history to understand the change.

A recorded redirect destination does not prove that the visitor opened it. Missing details or timestamps mean that evidence was not recorded.

For an outbound handoff, review the ordered trace of answer changes, routing, availability, link sharing, booking attempts, and delivery. A handoff may have several attempts. A link being created or opened is not a confirmed booking, and a confirmed booking can still have a delivery problem.

## Decide what to change

Use **Explain** where available to ask [Copilot](/copilot.md) about the recorded context. An explanation does not change the router.

Correct configuration in the relevant router, rule, form, or integration, then test and [publish the intended version](/routing/router-versions.md). The log itself does not rerun the prospect's journey. Historical attempts can retain earlier configuration even after the current router changes.

Use [Reporting](/reporting/overview.md) to compare trends across prospects, [Availability preview](/settings/calendar-troubleshooter.md) to investigate missing times, and [CRM activity](/crm/activity.md) for personal or group booking-link delivery.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.distro.so/reporting/routing-logs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
