> ## 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.

# How lead routing works in Default

> How Default picks an owner for each lead, CRM record, or meeting: queues, reusable routing policies, round robin, weighting, tiebreakers, eligibility checks, and the record of every assignment.

Lead routing in Default picks 1 person from a queue to own each inbound lead, CRM record, or meeting. The queue holds the people, the queue's routing policy decides
who goes next, and Default records every decision.

This page explains what the routing engine does once a queue has been chosen. To set up routing for
a specific CRM, see [Salesforce lead routing](/lead-routing/salesforce) and
[HubSpot lead routing](/lead-routing/hubspot).

## Lead routing in Default at a glance

Every routing decision in Default follows the same 4 steps:

1. **A routing step starts.** A workflow reaches a **Round-Robin** node, or someone books a Team
   event that a queue hosts.
2. **A queue is chosen.** The queue comes from the **Round-Robin** node's **Queue** field, from an
   earlier node such as **Match Default Record**, or from a
   [Rules of Engagement](/rules-of-engagement) rule.
3. **The queue's policy picks 1 member.** Default removes members who cannot take work right now,
   scores the rest with the policy's distribution rule, and breaks any tie.
4. **Default records the decision.** Later workflow nodes act on the chosen member. For example, an
   **Update Record** node writes that person as the record owner in Salesforce or HubSpot.

## Where routing runs in Default

| Where | What gets routed | What happens with the chosen member |
| - | - | - |
| **Round-Robin** node in a [workflow](/workflows/steps-routing-scheduling#round-robin) | A lead or CRM record | Later nodes use the member as **Latest assigned user**, for example to set the CRM owner or to notify them. |
| A Team [event](/events) with a queue as a host | A meeting | Default picks the member who hosts the booking. |
| **Rules of Engagement** node | A lead, after a rule chooses a queue | The queue's policy picks the member, the same way a **Round-Robin** node does. |

A workflow can start from any [trigger](/workflows/triggers), including a form submission, a CRM
record change, or a call from your own server through the
[API](/api/route-and-book).

<Tip>
  When a rule chooses a queue, the Rules of Engagement node already selects the member. Do not add a
  **Round-Robin** node after it for the same lead. See [Rules of Engagement](/rules-of-engagement).
</Tip>

## Queues and routing policies in Default

A queue in Default is a named group of people plus a pointer to 1 routing policy. The routing policy
is a separate, reusable object that holds the rules:

| Setting | Where it lives | What it controls |
| - | - | - |
| Members, weights, and active state | The [queue](/queues) | Who can receive work, and how much. |
| **Assignment Units** (**Objects**, **Meetings**) | The policy's **General** tab | Which kinds of work the policy routes and counts. |
| Distribution rule, tiebreaker, weighting, and reset schedule | The policy's **Assignment** tab | How Default scores members and picks 1. |
| Out-of-office and busy exclusions | The policy's **Availability** tab | Who Default skips at decision time. |
| Credits for cancelled, reassigned, and no-show meetings | The policy's **Credit Behavior** tab | When a member gets a turn back. |

1 policy can drive many queues. Each policy edit creates a new version, and every queue that uses
the policy runs the new version. See [Policies](/policies) for every option.

<Tip>
  A policy counts only the assignment units it routes. For a queue that assigns CRM record owners
  from a workflow, include **Objects** in the policy's **Assignment Units**.
</Tip>

## How Default picks a member from a queue

Once a queue has been chosen, Default runs these steps in order:

1. **Active members.** Default starts from the queue's active members. A member whose assignments
   are paused in the queue is skipped.
2. **Calendar check for meetings.** When the queue books a meeting, Default removes members who
   have no connected, active primary calendar. A **Round-Robin** or **Rules of Engagement** node
   only assigns an owner, so it skips this check.
3. **Availability exclusions.** Default then removes members that the policy's **Availability** tab
   excludes. By default, only **Exclude members currently out of office** is on. It covers
   out-of-office time set in Default or on the member's calendar.
4. **Distribution rule.** Default scores the remaining members with the policy's distribution rule.
5. **Tiebreaker.** If 2 or more members share the best score, the policy's **Tiebreaker rule**
   decides.
6. **Queue order, then join order.** If members are still tied, the order an admin set by dragging
   rows in the queue since the last reset decides. Without that order, the member who joined the
   queue first wins.
7. **Record.** Default saves the decision with the policy version it used and the scores of every
   member it scored.

If no member is left after the first 3 steps, a **Round-Robin** node fails and the workflow's
[run log](/workflows/run-logs) shows the error.

## Distribution rules in Default

The distribution rule is the main way Default scores queue members. Each policy has 1 rule, set on
its **Assignment** tab:

| Rule in the app | Also called | Who wins | Limits |
| - | - | - | - |
| **Take turns equally** | Round robin (the default) | The member with the fewest assignments. With weighting on, the fewest assignments per unit of weight. | None. Works for objects and meetings. |
| **Most available calendar time** | Availability | The member with the most free time in their work schedule around the meeting time. | Needs **Meetings** in **Assignment Units**. A **Round-Robin** node has no meeting time, so it fails on a queue whose policy uses this rule. |
| **Least recent assignment** | Recency | The member whose latest assignment is oldest. A member with no assignment yet goes first. | Weighting is not available. |

## Round robin in Default

**Take turns equally** is round robin in Default. For each member, Default keeps a count:

* Assignments since the last reset, for the assignment units the policy routes.
* Minus assignments that were credited back.
* Plus calibration credits an admin granted.

The member with the lowest count wins. For example, if 3 members hold 4, 4, and 3 assignments, the
member with 3 receives the next lead. When 2 members share the lowest count, the tiebreaker decides.

## Weighted distribution in Default

Weights let some members of a queue take a larger share of its work. To use them, turn on
**Enable weighted distribution** on the policy's **Assignment** tab. It is off by default. Then set
each member's weight in the queue with **Change weight**.

With weighted distribution on:

* **Take turns equally** divides each member's count by their weight. A member with a weight of 2
  receives about 2 assignments for every 1 that a member with a weight of 1 receives.
* **Most available calendar time** multiplies each member's free time by their weight.
* A member with a weight of `0` receives an assignment only when no eligible member has a weight
  above `0`.

With weighted distribution off, Default gives every member the same weight, whatever the queue shows.
Weighted distribution is not available with **Least recent assignment**.

## Tiebreakers in Default

A tiebreaker in Default picks the winner when 2 or more queue members share the best score. Set it
with **Tiebreaker rule** on the policy's **Assignment** tab:

| Tiebreaker rule | Who wins |
| - | - |
| **Recency** (the default) | The tied member whose latest assignment is oldest. |
| **Random** | A randomly selected tied member. |

When the distribution rule is **Least recent assignment**, only **Random** is offered.

If members are still tied after the tiebreaker, Default uses the order an admin set by dragging rows
in the queue's members table, then the order in which members joined. This mostly matters on a new or
reset queue under **Recency**, where nobody has an assignment yet. See [Ranking](/queues#ranking).

## Resets, calibration, and credits

Default keeps queue counts fair over time with 3 controls:

* **Assignment reset schedule** on the policy's **Assignment** tab clears assignment counts and
  calibration credits on a schedule: **Never** (the default), **Monthly**, or **Quarterly**. To
  reset a policy's counts at any other time, use the `routing_policy_reset` tool on the
  [Default MCP server](/mcp-server) (beta).
* **Calibration** adjusts 1 member's count, for example to bring a new member up to the queue
  average so they do not receive every new lead. See [Calibration](/queues#calibration).
* **Credit Behavior** gives a member a turn back when a meeting they received is cancelled,
  reassigned to another member, or marked as a no-show. **Enable crediting** and each of the 3
  toggles below it are on by default. Credits apply to meetings.

## When a CRM owner assignment counts in Default

A **Round-Robin** node picks a member right away. The pick counts toward that member's total only
after a later node uses it. The same applies when a **Rules of Engagement** rule chooses a queue and
the node picks a member from it. Default counts the assignment when all of these are true:

* A later **Create Record** or **Update Record** node writes the chosen member into the record's
  owner field, and the write succeeds.
* The field is the standard owner field: **Owner ID** on a Salesforce Lead, Contact, Account, or
  Opportunity, or the owner property (`hubspot_owner_id`) on a HubSpot Contact, Company, or Deal.
* The value comes from the node that picked the member: **Latest assigned user** after a
  **Round-Robin** node, or **Latest resolved user** after a **Rules of Engagement** node. A fixed
  user or typed text writes the owner but does not count.
* The queue's policy includes **Objects** in **Assignment Units**.

Each successful owner write counts once. If a workflow writes 1 pick to 2 records, for example a
contact and its company, the member's count goes up by 2.

Counted assignments appear in **Routing** under **Assignments**, on the **Object assignments** tab.
If a workflow run stops before the owner write, the pick does not count, and the next lead can go to
the same member.

## Review a routing decision in Default

Default keeps a detail view for every counted assignment. In **Routing**, select **Assignments**,
choose **Object assignments** or **Meeting assignments**, and open a row. The detail view shows:

* The record or meeting, and the **Assigned member**.
* **Queue configuration**: the settings that applied, such as **Distribution Strategy** and
  **Tiebreaker Strategy**.
* **Reasoning**: **Scored Members** with each member's score, **Tie-breaker applied** when there was
  a tie, **Selecting by queue position** or **Selecting by join order** when those decided, and
  **Determined Member**.

For a workflow, the [run log](/workflows/run-logs) also shows what each node did, including the
member a **Round-Robin** node assigned.

## Meeting routing and the Slots Rule

When a queue hosts a Team event in Default, the policy's **Slots Rule** on the **General** tab sets
how the booking page offers times:

| Slots Rule | Times the booking page shows | When Default picks the host |
| - | - | - |
| **All Active Members** | Times when any active member is free. | When the booking is made. |
| **Single Member** | Times for 1 member Default picks first. | Before times appear. The pick holds for that booking session. |

**Most available calendar time** requires **All Active Members**. See [Events](/events) to add a
queue as a host.

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.