Skip to main content
Human guide: work with your agent →
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 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 or HubSpot integration action before implementing it. 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 shows why usable enrichment and authorized writes need separate counts. Start a supported integration from the quickstart 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 for permitted customer storage writes and CRM provenance 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.