> ## 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. # Territory and segment routing in Default > Route leads by territory, region, segment, or company size in Default: 1 queue per territory team, chosen by Rules of Engagement, Multi-Branch conditions, or a territory value in your CRM, with existing account owners first. Territory routing in Default sends each lead to the team that covers its region, segment, or company size, then picks 1 rep from that team's queue. The territory decision uses the lead's data from your CRM, an enrichment provider, or a form, and every decision is logged. ## How territory routing works in Default Territory routing in Default combines 3 pieces: 1. **1 queue per territory team.** For example `NA Enterprise` and `NA Mid-Market` for North America (NA), and `EMEA Enterprise` and `EMEA Growth` for Europe, the Middle East, and Africa (EMEA). Each queue holds that team's reps and points at a routing policy. 2. **A step that chooses the queue.** A [Rules of Engagement](/rules-of-engagement) ruleset, a **Multi-Branch** node, or a **Match Default Record** node reads the lead's territory data and picks the queue. 3. **The queue's policy picks the rep.** Default applies the policy's distribution rule, for example **Take turns equally**, and a later **Update Record** node writes the rep as the owner in Salesforce or HubSpot. ## Choose a territory routing approach | Approach | How Default chooses the territory | Use it when | | - | - | - | | [Rules of Engagement](#route-by-territory-with-rules-of-engagement) | Ordered rules on CRM, enrichment, and form fields. The first rule that matches picks the queue or owner. | You have many territories, several workflows share them, or named accounts go to their existing owner. | | [Multi-Branch and Round-Robin](#route-by-territory-with-multi-branch) | Branch conditions inside 1 workflow, with a **Round-Robin** node on each branch. | You have a few territories and 1 workflow. | | [Match Default Record and Round-Robin](#route-by-a-territory-value-from-your-crm) | Finds the queue whose **Queue name** equals a territory value on the record. | Your CRM already stamps a territory on each record. | ## Territory data Default can route on | Data | Where it comes from | Examples | | - | - | - | | CRM fields | The workflow's **CRM Record Created** or **CRM Record Updated** trigger, or an earlier **Match Record** node | Country, State, Number of Employees, Annual Revenue, Industry, a custom territory field | | Enrichment | An earlier [**Enrich Data**](/workflows/steps-enrichment#enrich-data) node | Company size, company location, job title. The fields depend on the provider or waterfall. | | Form answers | The [**Form Submission**](/workflows/triggers#form-submission) trigger | A country or company size question on your demo form | | Existing ownership | An Account, Contact, or Company that **Match Record** finds | The account owner's user ID | When the form does not ask for size or location, add **Enrich Data** before the routing step so the rules have data to check. ## Set up 1 queue per territory team * **Create a queue for each team** in **Routing** → **Queues**. See [Queues](/queues). * **Share policies across queues.** 1 [policy](/policies) can drive every enterprise queue, for example with weighted distribution turned on. For owner routing, the policy must include **Objects** in **Assignment Units**. * **Put a rep in more than 1 queue** when they cover 2 territories. Each queue keeps its own assignment count for that rep. * **Map every rep to their CRM user** in [**Settings** → **Users**](/settings/users), so Default can write them as the owner. * **Keep a catch-all queue**, such as `Global Inbound`, for leads that match no territory. ## Route by territory with Rules of Engagement A Rules of Engagement ruleset in Default checks its rules from top to bottom and stops at the first match, so the order of the rules is the territory design. Put named accounts first, then size-based rules, then the broad regional rules. Example ruleset for Salesforce, with inputs from the Lead (Country, Number of Employees) and from the Account (**Owner ID**): | Order | Rule | Criteria | Route to | | - | - | - | - | | 1 | `Existing account owner` | Account **Owner ID** is not NULL | **User**: the Account **Owner ID** input. **Fallback**: the `Named Accounts` queue. | | 2 | `EMEA Enterprise` | Country is any of your EMEA countries, and Number of Employees is at least 1,000 | **Queue**: `EMEA Enterprise` | | 3 | `EMEA Growth` | Country is any of your EMEA countries | **Queue**: `EMEA Growth` | | 4 | `NA Enterprise` | Country is any of United States, Canada, and Number of Employees is at least 1,000 | **Queue**: `NA Enterprise` | | 5 | `NA Mid-Market` | Country is any of United States, Canada | **Queue**: `NA Mid-Market` | Leads that match no rule take the node's **Else** branch. Connect it to a **Round-Robin** node for the catch-all queue. To split a large region, add rules on State or a similar field above the regional rule, for example `NA West` for your western states. ### Route named accounts to their existing owner Rule 1 sends a lead to the owner of an account you already work. The ruleset can read the Account's owner only when the workflow has that Account before the Rules of Engagement node: 1. Add a **Match Record** node for the Account, for example **Website** **domain matches** the lead's email domain. See [Match an account by company domain](/workflows/steps-crm#match-an-account-by-company-domain). 2. On the **Match** branch, add the Rules of Engagement node. The matched Account fills the **Owner ID** input, and rule 1 routes to that owner. 3. On the **No Match** branch, add a Rules of Engagement node with the same ruleset. The Account input is empty there, so rule 1 does not match and the territory rules decide. If the Account has no owner, or its owner has no Default user mapping, the owner input is empty, so rule 1 does not match and the territory rules decide. If the owner is mapped but is no longer an active member of the workspace, rule 1 uses its **Fallback** queue. A lead routed to an existing owner does not count toward any queue's round robin. ### Write the owner back On the **Resolved** branch, add **Update Record** for the Lead and set **Owner ID** to **Latest resolved user**. For a queue rule, this write is what counts the assignment for the picked rep. If a queue can end up with no active members, check that **Latest resolved user** exists first. See [Rules of Engagement](/rules-of-engagement#what-the-workflow-receives-from-rules-of-engagement) for every value the node returns. ## Route by territory with Multi-Branch For a few territories in 1 workflow, branch on the lead's data and give each branch its own queue: After the trigger, or after **Enrich Data**, add **Multi-Branch**. Add a branch named `EMEA` with the condition Country is any of your EMEA countries, and a branch named `North America` for United States and Canada. Branches are checked in order, and the first match wins. Put a size-based branch, such as `NA Enterprise`, above the broad `North America` branch. On each branch, add **Round-Robin** with **Queue** set to that territory's queue. On **Else**, use the catch-all queue. After each **Round-Robin** node, add **Update Record** and set **Owner ID** to **Latest assigned user**. See [Multi-Branch](/workflows/steps-logic-timing#multi-branch) and [Round-robin](/workflows/steps-routing-scheduling#round-robin). ## Route by a territory value from your CRM When Salesforce or HubSpot already stamps a territory on each record, for example a custom Territory field with the value `EMEA Enterprise`, Default can pick the queue by name: 1. **Name each queue exactly like its territory value**, for example `EMEA Enterprise`. 2. **Add Match Default Record.** Set **Record** to **Queue**. In **Match Details**, set **Queue name** equals the record's Territory field. 3. **On Match, add Round-Robin** with **Queue** set to the matched queue. The data picker offers it as **Latest queue**. 4. **On No Match, add Round-Robin** for the catch-all queue, so a new or misspelled territory still gets an owner. See [Match Default Record](/workflows/steps-crm#match-default-record). ## Book the meeting with the territory rep To let a qualified lead book time with the rep the workflow picked, add [**Display Scheduler**](/workflows/steps-routing-scheduling#display-scheduler) after the routing step. Turn off **Use event hosts** and set the host from workflow data, such as **Latest resolved user** after Rules of Engagement or **Latest assigned user** after **Round-Robin**. A Rules of Engagement queue rule takes **Resolved** without a user when the queue has no active members. Check that **Latest resolved user** exists with a **Multi-Branch** node before the scheduler, so the lead is never shown a booking page with no host. ## Check a territory decision * The Rules of Engagement evaluation log shows which rule matched and why the rules above it did not. See [Review a routing decision](/rules-of-engagement#review-a-routing-decision). * **Routing** → **Assignments** shows how the queue scored its members and picked the rep. * The workflow's run log shows which branch each lead took. See [Why a lead went to a rep](/lead-routing/logs) for a step-by-step trace. 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.