> 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/rulebooks.md).

# Create a rulebook

A rulebook chooses an owner or queue from the lead's data. Use one when existing ownership, territory, company size, or another business rule should affect routing.

**Open Queues → Rulebooks.** Prepare the queues and the fields your rules need before publishing.

## Declare the inputs

Create a rulebook, enter its name, and open **Inputs**.

Add the sources and fields the rulebook will read. Sources include **CRM object**, **Enrichment**, **Form answers**, **Booking answers**, and **Lead fields**.

A rulebook only reads its declared fields. A workflow supplies those fields from the trigger and earlier steps. If a rule uses a CRM owner, put the relevant Match Record step before Apply Rulebook.

For an inbound demo rulebook, you might declare email, company size, region, and the matched account's owner.

## Add rules in priority order

Open **Rules** and select **New rule**. Name the rule, add its conditions, and choose **Route to**.

| Route to        | Use it for                                                              |
| --------------- | ----------------------------------------------------------------------- |
| **Queue**       | Distribute the lead among a pool.                                       |
| **Member**      | Send it to a specific teammate.                                         |
| **Owner field** | Use an owner supplied by an earlier CRM step or another declared input. |
| **No one**      | Deliberately stop assignment, such as a disqualified lead.              |

Rules run from top to bottom. The first matching rule decides; later rules are not checked. Put specific ownership and segment rules above broad fallbacks.

For example:

1. Existing customer with a usable account owner → Owner field.
2. Qualified enterprise prospect → Enterprise queue.
3. Other qualified prospect → Inbound queue.
4. Disqualified prospect → No one.

Use **Fallback when the member cannot be used** for an owner or member that cannot receive the lead.

## Handle blank values

A missing input can affect negative conditions. If a rule says “region is not Europe” and region is blank, it may still match.

Add **has a value** when the rule should only apply to known values. Keep a separate path for missing information.

## Save and publish

Select **Save draft**, review any reported problems, then **Publish**. Workflows apply the published rulebook, not the unpublished draft.

In the workflow, add **Apply Rulebook** after the steps that supply its inputs. Connect **Resolved** to scheduling or CRM updates and **Else** to a deliberate fallback or follow-up.

Applying a rulebook that selects a queue also selects the member. You do not need an extra Assign from Queue step on that path.

See [ownership and fallback](/routing/ownership-and-fallback.md) and [routing steps](/workflows/routing-steps.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/rulebooks.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 `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.