> For the complete documentation index, see [llms.txt](https://docs.distro.so/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.distro.so/routing.md). # Routing Choose who receives each lead and how your team takes turns. Routing answers two questions: **who should receive this lead**, and **how should eligible teammates take turns**? Use a **rulebook** for the first question. Use a **queue** and its **routing profile** for the second. ## Explore routing


Queues	Choose the teammates who can receive each assignment.	Create and manage a queue	distro3-queue.webp
Routing profiles	Set rotation, availability and turn-refund rules.	Routing profiles	distro3-profile.webp
Rulebooks	Route by ownership, territory or lead attributes.	Create a rulebook	distro3-rulebook.webp
Ownership and fallback	Keep existing relationships and handle unavailable owners.	Ownership and fallback	distro3-ownership.webp

## Choose the right setup | Situation | Use | | --------------------------------------------------- | -------------------------------------------------------------------------- | | Every lead goes to the same pool | A queue, used by Show Scheduler or Assign from Queue. | | Existing customers should reach their account owner | CRM matching, then a rulebook or the scheduler's CRM owner host source. | | Different regions or segments have different teams | A rulebook that selects the appropriate queue. | | Your CRM already stores a queue identifier | Find Queue, then assignment or scheduling. | | Leads need qualification before booking | Branch or a rulebook, with a separate path for leads that should not book. | ## What to set up first 1. Create a [routing profile](/routing/profiles.md). 2. Create a [queue](/routing/queues.md) with the eligible people. 3. Add a [rulebook](/routing/rulebooks.md) if routing depends on lead data. 4. Use those resources in a [workflow](/workflows.md). A queue can be reused across multiple workflows. That means those flows share its membership and rotation history. Create separate queues when your teams need separate pools or separate distribution history. Start with [ownership and fallback](/routing/ownership-and-fallback.md) if CRM owners should take priority. Use [logs and reports](/routing/logs-and-reports.md) to explain a particular decision. ## More guides * [Route a lead to its HubSpot owner](/routing/hubspot-owner.md) * [Route a lead to its Salesforce owner](/routing/salesforce-owner.md) --- # 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 dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.distro.so/routing.md?ask=&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 `build a script that syncs our docs to a CMS` 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.