> ## 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 HubSpot leads with verified owner IDs

> Validate HubSpot owner proposals against a labeled routing table before applying them.

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

Produce proposed owner assignments for a small contact sample. Confirm the owner mapping and protected records before applying changes.

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

A HubSpot owner ID is a destination identifier. A title, email, or team name is not automatically an accepted owner ID.

Test this fictional sample before calling providers:

| Case | Expected decision under this example policy |
| - | - |
| Eligible contact and known owner ID | Propose the rule-defined assignment |
| Protected current owner | Preserve ownership |
| No valid owner mapping | Hold instead of guessing |

## 2. Inspect supported operations

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline auth status --json
deepline search "HubSpot contacts owners properties" --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 `hubspot-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. Resolve existing HubSpot contacts and the intended company identities.
2. Inspect property types and available owners through supported actions.
3. Apply the stated territory, eligibility, and protected-owner rules.
4. Return proposed owner IDs, rule reasons, and exceptions. Keep writes disabled until the decision table passes.

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 hubspot-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 hubspot-lead-routing.play.ts --csv pilot.csv --watch
deepline runs get <run-id> --full --json
deepline runs export <run-id> --out hubspot-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

Check actual HubSpot record IDs and owner IDs against proposals. Verify repeated events do not produce contradictory assignments.

> [!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 enrichment](https://deepline.com/docs/guides/hubspot-enrichment-workflows.md) covers object identity. [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md) covers write verification.


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