Operations data · Research

Outsourced CRM field-change provenance for assistant updates

Why every delegated CRM correction needs a source, timestamp, proposed change, and accountable reviewer.

Headline statistic

A corrected field is trustworthy only when its source and decision remain visible

Methodology: Research question: what evidence should accompany a CRM field change prepared by an outsourced assistant? This review uses NIST SP 800-53 audit guidance, the ICO data-accuracy principle, and Salesforce data-quality documentation as claim-relevant references. It applies them to a proposed correction in one small team’s CRM and does not establish compliance or data accuracy by citation alone.

Key stats

  • Provenance links a proposed change to its source
  • Conflicts should remain visible instead of being silently merged
  • Accuracy and completeness are different measures

Key takeaways

  • Capture old value, proposed value, source, timestamp, and reviewer.
  • Escalate conflicting records instead of selecting the more convenient value.
  • Measure reversals and unresolved conflicts, not only completed edits.

Research question and source logic

A CRM correction is an assertion about a real person or organisation. The assistant may be able to locate evidence, but locating evidence is not the same as proving which record is authoritative. NIST audit concepts support retaining a useful trail, while the ICO accuracy principle makes the purpose and context of the data relevant to correction.

The test is therefore provenance: can a reviewer reconstruct what changed, why it was proposed, and who accepted it?

Research question and source logic evidence table
ItemFindingSource note
Required evidenceOld value, proposed value, source, time, reviewerNIST auditability interpretation
Accuracy boundarySource reliability still requires human judgementICO accuracy principle

Scenario analysis

Suppose two records contain different phone numbers. An assistant can compare timestamps, customer-provided records, and recent correspondence, then prepare a correction note. If the evidence conflicts, the correct output is a flagged merge question, not a guess. A cleaner database is not the objective if the correction destroys history.

For a fixed sample, count proposed changes with direct evidence, accepted changes, reversals, and unresolved conflicts. Keep the denominator tied to records reviewed so easy cases do not hide ambiguity.

Scenario analysis evidence table
ItemFindingSource note
Routine caseOne current source and a documented proposed updateOperational test
Exception caseConflicting sources or identity uncertaintyEscalation boundary

Conclusion and limitations

The evidence supports provenance as a practical control for delegated CRM work. It does not validate the source, decide retention obligations, or provide a compliance determination. The owner should set which fields require approval and which may be prepared for review.

The narrow conclusion is that an assistant can improve correction visibility without owning the truth decision. Expansion is justified only when the sample shows that evidence and reversals remain manageable.

Conclusion and limitations evidence table
ItemFindingSource note
ConclusionPreserve the decision trail, not just the new valueNIST, ICO, Salesforce synthesis
Not provenThat more edits mean better dataScope limitation

Related Research

Questions people ask

Should conflicting values be merged?

Not without an authorised decision and enough source context to explain the merge.

What is the minimum audit trail?

Keep the prior value, proposed value, source, timestamp, reason, and reviewer.

Sources

  1. 1. NIST SP 800-53 Revision 5Audit and accountability controls relevant to field changes.
  2. 2. ICO Accuracy PrincipleAccuracy, context, and correction principles.
  3. 3. Salesforce Data QualityCRM data-quality concepts; not a guarantee for a specific dataset.

Explore research briefing support · Review the SOP handoff checklist