> ## Documentation Index
> Fetch the complete documentation index at: https://deepline.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Route inbound leads with explicit exceptions

> Test a routing policy with known leads before changing CRM owners.

[Human guide: work with your agent →](https://deepline.com/docs/human/guides/inbound-lead-routing.md)

Test a routing decision table before connecting it to live writes. Keep ambiguous or ineligible leads in an explicit exception path.

## Before you start

Use an authorized workspace and a small file with stable source IDs.
Have source access and your team's acceptance policy available.
This guide describes customer-authored logic, not an automatically enabled product policy.

## 1. Understand the decision

Routing applies business policy to accepted identity and qualification evidence. Enrichment does not define territories or commercial ownership.

Test this fictional sample before calling providers:

| Case | Expected decision under this example policy |
| - | - |
| Eligible lead with exact territory match | Propose the rule-defined owner |
| Missing decisive geography | Use the explicit fallback or hold |
| Protected existing owner | Preserve ownership under this policy |

## 2. Inspect supported operations

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline auth status --json
deepline search "CRM company lead owner lookup" --type tools,prebuilts --json
```

Inspect a returned ID with `deepline describe <returned-id> --json`.
Compare required identifiers, outputs, access mode, and price.
A similar title does not establish that a contract fits.

## 3. Implement the bounded workflow

Ask your agent to author `inbound-lead-routing.play.ts` using [Write Plays](https://deepline.com/docs/sdk-v2/plays.md).
Have it declare the CSV input and preserve source IDs.
Reuse existing contracts when they fit the transformation.

Implement these rules explicitly:

1. Define eligibility, territory rules, fallback behavior, and protected ownership.
2. Resolve person and account identity before evaluating routing inputs.
3. Return the proposed owner and exact rule reason. Keep unknown inputs unresolved.
4. Test repeated events and conflicting ownership before enabling destination writes.

Keep external changes disabled for the first pilot.
That control belongs in the authored logic, not a universal Play dry-run flag.

## 4. Check and pilot

Prepare `pilot.csv` using [CSV-safe selection](https://deepline.com/docs/sdk-v2/batch-csv.md).
Then check the source:

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline plays check inbound-lead-routing.play.ts
```

Resolve authoring errors first. After reviewing source and price, run only the pilot:

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline plays run --file inbound-lead-routing.play.ts --csv pilot.csv --watch
deepline runs get <run-id> --full --json
deepline runs export <run-id> --out inbound-lead-routing-review.csv
deepline billing usage --run-id <run-id> --json
```

Use the ID returned by the pilot. Select a returned dataset path when several
exist. Provider-backed execution can incur usage.

## 5. Verify the outcome

Compare proposed owners with a labeled decision table. Count unresolved leads separately from assignments and request failures.

> [!TIP]
>
> Every source ID has a result or explicit exception. The fictional cases follow
> the stated policy, and actual results retain their evidence.

Ask your agent why a record was accepted, held, or rejected.
Correct the rule before expanding input or enabling external writes.

## Continue

[HubSpot routing](https://deepline.com/docs/guides/hubspot-lead-routing.md) applies the boundary to a CRM. [Governance](https://deepline.com/docs/guides/crm-data-governance.md) explains authority.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.