TL;DR
- A CRM history row can show who changed a field without explaining which agent run, evidence or decision produced it. Join those records explicitly.
- Salesforce Field Audit Trail fits persistent native field history. Workato fits the execution record of an integration. Neither should be bought as an automatic undo system.
- In HubSpot, inspect the audit categories and property history available in your subscription before assuming an API write is fully explained by the central audit log.
- Preserve the old value and the exact value written. Reverse only if the current record still matches that write, or route the conflict to a person.
- For 2,000 monthly writes, completeness of the audit record matters more than the number of logs collected. Protect evidence from routine execution pruning.
Why an integration username is insufficient
A sales agent changes an account's industry from Manufacturing to Logistics. The CRM history names a service account. The integration dashboard says the job succeeded. Neither tells the account owner whether the agent used a company website, a stale enrichment response or a different subsidiary's profile.
A useful audit connects the business mutation to its cause. It identifies the execution, the authenticated actor, the evidence selected, the rule or decision version and the exact fields changed. That connection is the purchase requirement. Buying longer retention for an incomplete record only preserves the uncertainty for longer.
This guide concerns changes that have already happened. Our CRM agent platform comparison covers supported writes and platform choice; the human approval guide covers authorisation before execution. A trace of model reasoning also differs from a confirmed database mutation. An intended update may fail, partially complete or succeed after a retry.
Use the RevOps CRM setup playbook to define field ownership before adding auditing. It is difficult to reverse a change safely when nobody has decided whether sales, enrichment or a finance integration owns that field.
The evidence record to retain
Keep one action identifier across proposal, execution, CRM confirmation and any correction. A useful record contains the following information.
| Evidence | What it answers | Important boundary |
|---|---|---|
| CRM organisation, object and record ID | Which business record changed? | A display name is insufficient after a rename or merge |
| Field name, previous value and written value | What was replaced? | Preserve types and nulls rather than converting everything to text |
| Service principal and agent run ID | Which authenticated process made the write? | A shared user needs additional workflow attribution |
| Source evidence IDs and retrieval time | What supported the decision? | Retain a permitted extract or durable reference, not a temporary URL alone |
| Workflow, mapping and policy version | Which instructions were in force? | A current workflow cannot explain an older run reliably |
| Request, response and confirmation time | Was the write actually applied? | An HTTP timeout is not proof that nothing happened |
| Reversal action and current state | What was corrected later? | Correction is another auditable change |
Record the operation's outcome separately from the business judgement. “API accepted” does not establish that the industry classification was correct. Store failed attempts and retry relationships so three requests do not become three apparent business changes.
Avoid copying entire conversations into every audit row. Retain the evidence needed to explain the decision, restrict its access and apply an appropriate retention policy. An audit store containing raw customer data is another system that needs protection.
Native history and integration logs compared
| Layer | Strongest contribution | What remains to build |
|---|---|---|
| Native CRM field history | Change evidence close to the system of record | Join to the agent run and source evidence |
| Integration job history | Inputs, execution path, errors and retries | Confirm the database result and durable retention |
| Dedicated mutation ledger | Cross-system action ID and reversal state | Reliable capture, access controls and reconciliation |
| Backup and recovery | Earlier recoverable state | Selective restoration that respects subsequent valid changes |
Use native history as corroboration, not as a replacement for execution attribution. If all writes arrive through one integration identity, its username is correct but not sufficiently specific for investigation.
Similarly, an integration can log a proposed value before the CRM rejects it. Reconcile the ledger against confirmed writes. Where a request times out, query the destination before replaying it. The CRM activity sync guide explains the wider ownership and duplication problem; the audit must preserve those same event identities.
Buying the right audit layer
Salesforce Field Audit Trail and Shield
Salesforce's Field Audit Trail documentation describes a licensed extension for field-history retention. It is the natural starting point for a Salesforce organisation that needs governed history on important fields. Inspect supported objects and tracked fields against the exact automation, rather than enabling a few convenient fields and assuming the whole process is covered.
The public Shield pricing page lists Field Audit Trail at 10% of applicable net spend and the Shield suite at 30%. The denominator is qualifying Salesforce product spend, not a per-write fee. Obtain the applicable-product definition and contract treatment in the quote. Shield also bundles security capabilities, so it can make sense for an organisation buying that wider control set.
Choose Field Audit Trail when persistent native history is the missing layer. Avoid buying the full suite solely to identify which prompt produced a write: the application still needs the run-to-record join. Field history also does not establish a safe, automatic reversal of downstream business actions.
Workato for governed integration execution
Workato fits organisations whose CRM changes already pass through managed integration recipes. Its job records can help reconstruct the execution and distinguish failures from completed runs. The key procurement issue is preservation: Workato's retention documentation describes default periods varying by workspace and plan, and audit-log streaming for longer storage.
Confirm which streamed events contain the before/after business values you need. A workspace administrative audit is not necessarily a complete mutation ledger. Include external storage, monitoring and investigation access in the scoped platform-and-usage offer.
Our buying judgement: use Workato's evidence when it is already the write path, then extend it with action IDs and destination confirmation. Adding a second automation platform merely to obtain a log viewer usually creates another attribution boundary.
HubSpot native records
HubSpot's centralised audit-log guide explains viewing and exporting user actions, with subscription-dependent coverage. Start with the categories actually available in your account and the properties being changed. Demonstrate an API update, workflow update and manual correction in the evaluation.
This is a sensible first layer for a HubSpot team, particularly if its existing subscription already provides the required evidence. It is a poor basis for assuming every agent-generated property change includes its source, prompt and previous value in one central record. Budget any required subscription upgrade separately from the mutation ledger.
n8n with an external ledger
n8n suits a technical operations team that owns the workflow and can persist an explicit audit event. Its execution-data guidance describes configurable saving and pruning. That makes the default troubleshooting history a weak long-term evidence archive unless retention is deliberately configured.
Write the confirmed mutation record into a governed store independently of routine execution cleanup. Account for hosting or cloud execution charges, database backups, access controls and the person maintaining the joins. Choose this route for control over the evidence contract; avoid it when nobody can own its reliability. A low subscription does not make an unmaintained audit system inexpensive.
Product documentation and public pricing were checked on 6 October 2026. The recommendations concern architecture and purchasing fit, not a hands-on audit completeness benchmark.
Reversing a change without overwriting the next one
Suppose the agent writes Logistics at 09:00. At 10:00 an account owner corrects the value to Transport Services. At 11:00 an investigator requests reversal of the agent's update.
Blindly restoring Manufacturing would erase the later correction. The reversal service should first compare the current value with the value written by the original action. If it still matches Logistics, a conditional correction can restore Manufacturing. If it differs, stop and show the conflict to the field owner. Use the CRM's available concurrency mechanism or an explicit read-and-check design; do not promise an atomic guard that the destination does not support.
Reversal must also examine side effects. A stage update may have triggered a task, notification or billing handoff. Returning the field to its old value does not unsend a message. Record those consequences and assign separate compensating actions where permitted.
Never delete the original history to make the record look clean. Retain the correction's actor, reason and link to the original action. The audit should explain both decisions.
An audit budget for 2,000 writes
Consider a hypothetical Salesforce deployment with $60,000 annual applicable net spend. At the public Field Audit Trail percentage, the planning figure is $6,000 a year, or $500 a month. This illustration is subject to the final applicable-spend definition and quote.
Add assumed ledger storage/monitoring of $100 a month and five investigation hours at $60: $900 monthly, before implementation, tax and other licences. At 2,000 confirmed writes, that is $0.45 per audited write if every write has complete evidence.
If only 1,800 have the required run, values and source reference, the denominator is 1,800 and the cost becomes $0.50 per explainable write. More importantly, 200 mutations remain unaccounted for. A cost metric should not conceal that failure.
An assumed 20-hour setup at $60 adds $1,200 in the first period. If monthly investigations rise from five to fifteen hours, recurring cost rises by $600. If applicable Salesforce spend doubles, the illustrated Field Audit Trail component doubles. Those are the two dominant sensitivities in this example; storage alone is unlikely to be the whole purchasing decision.
The acceptance drill
Use controlled records to create a correct update, rejected update, timeout after a write, duplicate retry and later manual correction. For each, reconstruct the actor and confirmed result without asking the original operator to remember what happened.
Then request a reversal. The unchanged record should follow the permitted correction path; the manually corrected record should surface a conflict. Check that evidence survives the planned execution-history retention window and remains accessible only to authorised investigators.
Buy the layer that closes the demonstrated gap. Longer CRM history, better integration attribution and recoverable backups solve different problems. A complete, joined record is the condition for buying judgement, rather than the presence of an “AI governance” label.
FAQ
Does a CRM audit trail explain an AI decision?
It may explain the database change, including its actor and time, but the agent's supporting evidence normally requires another record. Join the confirmed mutation to the run, source IDs and decision version. A model trace without confirmation is equally incomplete.
Can every AI change be undone automatically?
No. Later valid edits, record merges and downstream actions can make simple reversal unsafe. Automate the uncomplicated case with a current-state guard, and send conflicts or consequential side effects to an accountable owner.
Should we retain full prompts indefinitely?
Retain what the investigation and governance policy requires, with controlled access. Evidence IDs, permitted extracts and policy versions may explain a classification without duplicating all personal information. Define that retention separately from temporary execution troubleshooting.
Is backup a substitute for field auditing?
Backup can recover an earlier state, while auditing explains the changes between states. Bulk restoration can overwrite valid work created after the backup. Use the audit to select and justify the recovery scope, then verify restored relationships and consequences.
