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.Key takeaways
- Define field ownership, precedence, freshness, and validation rules before automating any CRM write.
- Preserve the old value, proposed value, evidence, workflow version, and result for every attempted change.
- Send ambiguous identities, conflicting evidence, and protected fields to a review queue instead of forcing an update.
Who this is for
Sales operations leaders who need to improve routing, reporting, and follow-up without breaking trusted customer records.Decision guide
Operating method
- Inventory the fields used in routing, reporting, lifecycle transitions, and customer communication.
- Set a field-level rule: requiredness, format, source of truth, owner, freshness period, and allowed writer.
- Run a daily exception scan that labels each problem type and assigns a repair owner and due date.
- Apply deterministic repairs only when evidence is explicit. Produce a proposal for all other repairs.
- 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 contains the CRM ID, field, previous value, proposed value, source URL or source record, observation time, 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.
Implementation details
- Read the current CRM value before every write. Skip unchanged fields and reject writes when the source record changed after the workflow began.
- Assign one authorized writer per field. Keep enrichment evidence separate from sales-owned notes, lifecycle stage, and opportunity data.
- Use a dry-run output with proposed changes, reasons, and source links before enabling writes for a new object type or field set.
- After the write, read the record again and store the observed value. Route partial writes and permission failures to a named repair queue.
Common failure modes
- Using one completeness score for fields with very different business importance.
- Letting several tools write the same CRM property.
- Hiding failed workflow writes as empty output.
- Cleaning records without identifying the upstream process that made them dirty.