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

# CRM data quality automation: validation and safe writes

> Design CRM data quality automation with ownership, validation, provenance, exception queues, and safe write-back controls.

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

> [!NOTE]
>
> Create a field-level CRM proposal and retain the evidence needed to explain or
> reject it.

CRM data quality automation works when it is a control system, not a bulk cleanup button. Each rule needs a target field, allowed evidence, record owner, correction method, and exception path. The system should create a proposed change, verify it against the CRM, and make every write attributable to a workflow version.

## Validate the import before CRM repair

For incoming CSV files, use the [file validation guide](https://deepline.com/docs/guides/validate-incoming-csv-files.md) to check headers, row identity and exception counts before enrichment or CRM writes.

Keep rejected rows with their source identity and repair reason. Reconcile every input row to an accepted or explicit exception state before handing the file to another workflow.

## Operating method

1. Inventory the fields used in routing, reporting, lifecycle transitions, and customer communication.
2. Set a field-level rule: requiredness, format, source of truth, owner, freshness period, and allowed writer.
3. Run a daily exception scan that labels each problem type and assigns a repair owner and due date.
4. Apply deterministic repairs only when evidence is explicit. Produce a proposal for all other repairs.
5. Measure exception aging, repeat failures, and the percentage of decisions made on verified data.

## Example: propose an email update without overwriting a trusted value

This is an illustrative decision workflow, not an automatically enabled CRM safeguard. Inspect the current [Salesforce integration](https://deepline.com/integrations/salesforce) or [HubSpot integration](https://deepline.com/integrations/hubspot) action before implementing it.

| Check | Accepted path | Exception path |
| - | - | - |
| Identity | Exact CRM ID and matching person/company evidence | Review ambiguous or conflicting identities |
| Ownership | Destination field is empty or explicitly owned by this workflow | Preserve sales-owned and protected values |
| Freshness | Source observation is within the team's documented window | Recheck stale evidence |
| Change review | Proposal records previous value, new value, source and approval | Do not infer approval from a completed enrichment |
| Write | Re-read current value, submit only approved fields, then read back | Reconcile changed records and ambiguous outcomes before retrying |

A suggested audit record includes:

* CRM ID and field
* Previous and proposed values
* Source URL or source record
* Observation time and workflow version
* Reviewer decision and verified write result
  Keep sensitive values in an approved system. An audit record is not a rollback guarantee, and a read-before-write check is not an atomic compare-and-set unless the CRM action explicitly supports one.

The [enrichment evaluation guide](https://deepline.com/blog/data-enrichment-guide-2026) shows why usable enrichment and authorized writes need separate counts. Start a supported integration from the [quickstart](https://deepline.com/docs/quickstart.md) and test on an internal account before updating customer records.

## Retain a field-level decision record

Keep a decision record in customer-owned working data when the process needs
provenance across runs. This is a workflow design, not an automatically created
CRM audit table.

1. Connect the source identity to the exact CRM object ID. Preserve ambiguous
   candidates rather than selecting one without evidence.
2. Record the prior value, proposed value, source, and available observation
   time. Keep retrieval time distinct from the source's observation time.
3. Record the acceptance rule, validation outcome, workflow version, and run ID.
   Keep unknown evidence fields explicitly unknown.
4. Apply the field's ownership and precedence policy. Preserve rejected or
   review-required proposals without overwriting the operating field.
5. Record the attempted write and observed destination value. Keep an uncertain
   timeout separate from a confirmed rejection or verified update.

A read-before-write check does not provide atomic concurrency protection.
Use a destination-supported conflict policy or explicit reconciliation where
other writers can change the same field. Store only the evidence your process
needs under its retention and data-use policy.

See [Query Database](https://deepline.com/docs/database-access.md) for permitted customer storage
writes and [CRM provenance](https://deepline.com/docs/guides/data-provenance-in-crm.md) for the reasoning.

## Verify this task

Check exact destination identity, field ownership, evidence time, prior value, and proposed change. Verify write outcomes separately from proposals.

Ask your agent to explain a failed check before repeating work or expanding the scope.


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