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

# Automate reviewed CRM changes

> Create reviewed CRM proposals with explicit ownership and uncertain-write handling.

[Human guide: work with your agent →](https://deepline.com/docs/human/guides/crm-workflow-automation.md)

Produce proposed CRM changes for a small sample. Confirm record identity and protected fields before enabling writes.

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

Technical permission to update a CRM does not decide which fields a workflow should change. Define business authority separately.

Test this fictional sample before calling providers:

| Case | Expected decision under this example policy |
| - | - |
| Accepted proposal for workflow-owned field | Permit under the example policy |
| Protected field conflicts | Hold for review |
| Timeout after submission | Reconcile before repeating |

## 2. Inspect supported operations

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline auth status --json
deepline search "CRM read contact company update" --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 `crm-workflow-automation.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 the exact destination object and retain its stable ID.
2. Read the current value and apply field ownership and precedence.
3. Return proposals, evidence, and protected-field exclusions.
4. Implement destination-supported idempotency or reconciliation before enabling 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 crm-workflow-automation.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 crm-workflow-automation.play.ts --csv pilot.csv --watch
deepline runs get <run-id> --full --json
deepline runs export <run-id> --out crm-workflow-automation-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

Confirm the first pilot produced proposals without writing. For authorized write testing, compare observed state with the approved proposal.

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

[CRM repair](https://deepline.com/docs/guides/crm-data-quality-automation.md) supplies field-level steps. [Production integration](https://deepline.com/docs/sdk-v2/production-integration.md) covers external writes.


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