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

# Build a phone acceptance workflow

> Build a phone review file with line-type, validation, and identity evidence.

[Human guide: work with your agent →](https://deepline.com/docs/human/guides/phone-enrichment-workflows.md)

Test one phone policy against valid mobile, valid landline, and unresolved cases. Keep line validation separate from the decision to contact someone.

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

The maintained person-to-phone route accepts a valid line by default. Mobile-only tasks require `require_mobile: true`.

Test this fictional sample before calling providers:

| Case | Expected decision under this example policy |
| - | - |
| Validated mobile under mobile-only policy | Accept after identity review |
| Validated landline under mobile-only policy | Reject as non-mobile |
| Request error without a number | Record an error, not invalidity |

## 2. Inspect supported operations

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline auth status --json
deepline search "person mobile phone validation" --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 `phone-enrichment-workflows.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. Preserve the person identity and supplied country context.
2. Inspect person-to-phone and decide whether a valid landline is acceptable.
3. Use supported fields without assuming automatic geographic provider selection.
4. Retain line type, validation, source, rejected candidates, and no-result evidence.

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 phone-enrichment-workflows.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 phone-enrichment-workflows.play.ts --csv pilot.csv --watch
deepline runs get <run-id> --full --json
deepline runs export <run-id> --out phone-enrichment-workflows-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

Inspect actual phone validation, line-type, and rejection fields. National-format normalization does not establish provider selection.

> [!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

[Find mobile phone](https://deepline.com/docs/plays/task-find-mobile-phone.md) provides a maintained lookup. [Profile review](https://deepline.com/docs/guides/verified-contact-details-from-profiles.md) covers identity.


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