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

# Review and repair pipeline records

> Build a repair queue for critical pipeline fields without guessing commercial changes.

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

Produce a review queue of stale or inconsistent opportunity records. Separate a proposed repair from an approved CRM change.

## 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 missing field can require evidence, an owner decision, or an integration repair. Those exceptions need different responses.

Test this fictional sample before calling providers:

| Case | Expected decision under this example policy |
| - | - |
| Close date passed without new evidence | Flag for owner review |
| Missing owner | Apply the documented ownership process |
| CRM retrieval failed | Report an operational error |

## 2. Inspect supported operations

```bash theme={"languages":{"custom":["/languages/deepline-prompt.json"]}}
deepline auth status --json
deepline search "CRM opportunities activities read" --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 `pipeline-hygiene.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 critical fields and freshness rules for this pipeline review.
2. Read records and supporting activity without changing them.
3. Separate missing evidence, stale observations, policy conflicts, and access errors.
4. Return proposed repairs and evidence without inventing stages, close dates, or commitments.

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 pipeline-hygiene.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 pipeline-hygiene.play.ts --csv pilot.csv --watch
deepline runs get <run-id> --full --json
deepline runs export <run-id> --out pipeline-hygiene-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 the reason and evidence for each exception. A proposed repair is not a completed CRM change.

> [!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) covers controlled corrections. [Revenue quality](https://deepline.com/docs/guides/revenue-data-quality.md) explains decision fitness.


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