A CRM activity log is the history of work: calls, meetings, tasks, and notes that users add to a lead, contact, or opportunity. An audit trail is the history of changes: which user changed which field, the old value, the new value, and the time. Teams often use “history” for both. They answer different questions.
“Did anyone call this customer?” is an activity question. “Who moved this deal to Won, and what was the amount before?” is an audit question.
What a useful activity record contains
Each activity should store:
- Type (call, meeting, task, note)
- Related record (the opportunity or account, not a floating note)
- Owner
- Date and time, including whether the task is still open
- A short outcome, not only “called”
Activities are for humans. They will be incomplete if logging is painful. Required fields should stay few. A next step and a date beat a long form nobody fills.
What an audit trail should capture
For fields that affect money, ownership, or stage, capture:
- Field name
- Previous and new value
- User or integration that made the change
- Timestamp and, if relevant, the record ID
Stage, amount, close date, owner, and discount are typical audited fields. Auditing every keystroke on a notes box creates noise. Choose fields whose change would start an argument.
Integrations must appear as a named system user, not as a shared human login. Otherwise a price update from accounting looks like a salesperson edited it.
Reading a disputed deal
- Open the opportunity and list its activities
- Check the audit entries for stage, amount, and owner
- Separate human edits from integration updates
- Confirm the timestamps against the quotation file
- Record the conclusion in a note, without rewriting history
Retention is a policy
Some products keep field history for a fixed period. Some keep it until you turn the feature off. Decide how long you need stage and amount history for disputes and reporting, and test that you can still see a change from that long ago. If the product cannot retain what you need, export the audit on a schedule to storage you control. That limitation is a product fact to discover in a trial, not a claim that every CRM stores history forever.
Deletion of a record should not silently erase the only evidence of who exported it. Prefer deactivation, and restrict delete rights as described in CRM user permissions.
What to turn on first
If you cannot audit every field on day one, start with stage, amount, owner, and the marketing-consent flag. Those four explain most internal disputes. Add discount and close date once the first set is visible in the interface and someone has opened it during a real argument. Export a sample of the trail after a week of normal use. If the export is empty, the feature is not actually recording, regardless of the settings screen.
A practical example
A manager asks why a deal shows Won at RM 10,000 when the quotation was RM 12,000. The activity list shows a call, but not the amount change. The audit trail shows an integration user updated the amount when the accounting document was revised, two days after a salesperson moved the stage. The team now knows the stage change and the amount change were different events, by different actors.
Key takeaways
- Activities describe work people did.
- Audit trails describe field changes and who made them.
- Audit commercial fields and ownership, and name integration users.
- Confirm how long history is kept before you rely on it in a dispute.
FAQ
Is an email copied onto the record an audit trail?
No. It is an activity or a logged message. It does not prove who later edited the opportunity amount.
Should customers see the audit trail?
Usually no. Internal history can contain margins, lost reasons, and staff names. Customer-facing portals need a separate, smaller history.
Can workflow rules write the audit?
The CRM should audit the change whether a person or a workflow made it. Workflow design itself is covered in how CRM workflow automation triggers work. The audit answers who or what ran, not whether the rule was wise.