> ## Documentation Index > Fetch the complete documentation index at: https://docs.os.default.com/llms.txt > Use this file to discover all available pages before exploring further. # Why a lead went to a rep: routing logs in Default > Trace any routing decision in Default: the assignment detail with scored members, tiebreaker, and determined member, the workflow run log, the Rules of Engagement evaluation log, and the routing activity log. Default records every routing decision, so you can answer why a lead, CRM record, or meeting went to a specific rep. The records show which workflow path the lead took, which Rules of Engagement rule matched, how the queue scored its members, and how any tie was broken. ## Where Default records routing decisions | Record | Where to find it | What it answers | Who can see it | | - | - | - | - | | Assignment detail | **Routing** → **Assignments** | Which queue member won, their score against the other members, and how a tie was broken. | Admins | | Workflow run log | **Workflows** → the workflow → **Runs** | Which trigger fired, which branches the run took, and what each node did, including errors. | People with access to the workflow | | Rules of Engagement evaluation log | **Routing** → **Rules of Engagement** → the ruleset → **Logs** | Which rule matched, and why the rules above it did not. | Admins | | Routing activity | **Routing** → **Activity** | Who changed a queue, a member, or a policy, and when. | Admins | | [MCP server](/mcp-server) (Beta) | An AI client connected to Default over the Model Context Protocol (MCP) | The same decision record, plus members that were excluded and routing requests that failed. | Admins and owners | ## Trace 1 lead from start to finish Open the routing workflow and select **Runs** in the top bar. Search for the lead's email in **Search record, email, or status…**, then open the run. In **Run Details**, each step shows what it did. A **Multi-Branch** step shows every condition with **TRUE** or **FALSE**. A **Round-Robin** step reads **Assigned to**, followed by the rep. A Rules of Engagement step shows its result and a **view evaluation** link. For a Rules of Engagement step, expand it or select **view evaluation** to see every rule, the inputs it received, and the rule that decided. In **Routing**, select **Assignments**, then **Object assignments** for CRM owner routing or **Meeting assignments** for bookings. Find the lead and open the row to see the scores behind the pick. If the result looks wrong, open **Routing** → **Activity** to see whether someone paused a rep, changed a weight, or edited the policy around that time. ## The assignment detail view Default keeps a detail view for every assignment a queue makes. In **Routing** → **Assignments**, open a row on **Object assignments** or **Meeting assignments**. The detail view shows these cards: | Card | What it shows | | - | - | | **Open Source** | A button that opens the workflow run that made the assignment, when a workflow made it. | | **Record** or **Meeting status** | The routed CRM record, or the meeting and its status. | | **Assigned member** | The rep who received the assignment. | | **Queue configuration** | The settings that applied: **Assignment Type**, **Distribution Strategy**, **Tiebreaker Strategy**, and **Slots Strategy**. | | **Reasoning** | Each step of the decision, in order, with timestamps. | The **Reasoning** card lists these steps: | Step | When it appears | What it shows | | - | - | - | | **Selected Timeslot** | Meeting assignments | The step where the meeting's time slot was chosen. | | **Scored Members** | Always | Every eligible member and their score under the distribution rule. The winner comes first, with a check mark. | | **Tie-breaker applied** | 2 or more members shared the best score | The tiebreaker rule and the tied members' scores. | | **Selecting by queue position** | Members were still tied after the tiebreaker | The member an admin placed first in the queue won. | | **Selecting by join order** | Members were still tied, with no queue order set | The member who joined the queue first won. | | **Determined Member** | Always | The member who received the assignment. | What each score means depends on the policy's distribution rule. The **Queue configuration** card names the rule the way the routing engine does: | Rule in the policy | Name in the detail view | Score shown for each member | | - | - | - | | **Take turns equally** | Round Robin | The member's assignment count, for example `3 assignments`. | | **Least recent assignment** | Recency | The time of the member's latest assignment, or `Never`. | | **Most available calendar time** | Availability | The member's free time in their work schedule. | Hover a member's score to see their weight, calibration credits, score, latest assignment, and, for availability, the time available. The scores come from the policy version that made the decision, which can be older than the queue's current policy. See [Policies](/policies) for the distribution rules and tiebreakers, and [Ranking](/queues#ranking) for queue order. ## Which decisions appear under Assignments * **Meeting assignments** lists every meeting a queue assigned, with **Person email**, **Queue name**, **Distribution rule**, **Assigned to**, **Source** (**Workflow**, **Scheduler**, **Booking link**, **Default extension**, or **Reassign**), **Created at**, and **Meeting status**. * **Object assignments** lists CRM owner assignments, with **Record**, **Object type**, **Assigned to**, **Queue**, and **Timestamp**. A queue pick from a **Round-Robin** or Rules of Engagement node appears here once a later node writes that rep as the record's owner. * **A Rules of Engagement rule that routes to a user** does not go through a queue, so it has no assignment row. Its evaluation log records the decision. To keep a copy, select **Export to CSV**. Choose **All Records** or **Records in filtered view**, and Default emails the CSV to you. ## Routing steps in the workflow run log The [run log](/workflows/run-logs) records what each routing step did in a workflow run: | Step | What the run log shows | | - | - | | **Round-Robin** | **Assigned to** and the rep, or the error, for example when the queue is turned off or has no active members. | | **Rules of Engagement** | The outcome (user, queue, no one, or unresolved) and a **view evaluation** link. Admins can expand the step to see every rule it checked, then a **Resolved member** or **Resolved queue** card. | | **Multi-Branch** | The branch it took and every condition with **TRUE** or **FALSE**. See [Branch and condition nodes](/workflows/run-logs#branch-and-condition-nodes). | | **Update Record** | Under **Show data**, the fields it wrote, including the owner. | ## Rules of Engagement evaluation log Each Rules of Engagement ruleset in Default has a **Logs** tab that lists its evaluations from the last 7 days. Each evaluation shows the inputs the ruleset received, every rule in the order Default tried them, which rule matched, and why earlier rules did not match. See [Review a routing decision](/rules-of-engagement#review-a-routing-decision). ## When no rep was assigned | What you see | Where to look | | - | - | | No workflow run for the lead | Check that the workflow is published and its status reads **Live** (see the [deployment switch](/workflows#the-enabled-switch)), and that the lead meets the trigger's **Condition**. | | The run failed at **Round-Robin** | The step's error in the run log. The queue may be turned off, have no active members, or have every member excluded, for example because all are out of office and the policy excludes out-of-office members. | | The Rules of Engagement step took **Else** | The evaluation: no rule matched, a rule routed to **No one**, or the queue could not be used. | | A rep was picked, but the CRM owner did not change | The **Update Record** step in the run log. A common cause is a rep with no CRM user mapping in **Settings** → **Users**. | | The pick is missing from **Assignments** | The owner write never ran or failed, so the pick did not count. Check the **Update Record** step. | With the [MCP server](/mcp-server) (Beta), `lookup_assignments_by_email` also lists failed routing requests for an email address, which produce no assignment row. ## See who changed the routing setup **Routing** → **Activity** records every routing change in Default: queue and policy creates, edits, and deletes, member adds, removals, weight changes, moves, and calibrations, system credits, and assignment resets. Filter by queue, user, the person who made the change, activity type, and date. See [Activity log](/queues#activity-log). ## Ask about a routing decision from an AI client The Default [MCP server](/mcp-server) is in beta. Its queue and routing tools answer the same questions from an AI client connected over MCP, in workspaces where those tools are turned on: * `explain_assignment` returns the decision record for 1 assignment: the distribution rule and tiebreaker, the winner's score, every other eligible member's score, and each excluded member with the reason. * `lookup_assignments_by_email` lists a lead's assignments, newest first, and any failed routing requests for the same email. * `list_assignments` and `list_routing_activity` browse the assignment log and the change log. For example, ask "Why did this lead go to Jordan? Explain the assignment." Related: [Lead routing software from Default](https://www.default.com/product/lead-routing-software) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.