How do I set up audit trails and change history?
Short answer
Turn on activity logging for the record types that matter most, such as financial fields and pipeline stage changes, and make sure every team member logs in under their own account rather than a shared one. A clear change history lets you answer who changed what and when, without guessing.
Before you start
- Individual logins for every team member, not a shared account.
- Access to activity or change history logs on key record types.
- Agreement on which fields or actions need the closest tracking.
- A recurring time set aside to review the history.
Step by step
- 1
Require individual logins for every user
Shut down shared logins and give each team member their own account.
A shared login makes every audit trail useless because you cannot tell who did what.
- 2
Identify the fields that need the closest tracking
Payment status, pipeline stage, and permission changes are the usual priorities.
You cannot track everything with equal attention, so focus on what carries the most risk.
- 3
Turn on activity logging for those record types
Enable history tracking on contacts, invoices, and pipeline stages at minimum.
Logging has to be active before a change happens, not after someone asks about it.
- 4
Check that timestamps and user names are captured
Confirm the log shows who made a change and exactly when, not just what changed.
A log that only shows the change without the author cannot answer accountability questions.
- 5
Restrict who can edit sensitive fields
Limit editing of financial and permission fields to specific roles.
Fewer people with edit access means a shorter, more useful audit trail.
- 6
Review the change history on a schedule
Check the log weekly or monthly for unexpected changes to sensitive records.
An audit trail nobody reviews only helps after something has already gone wrong.
- 7
Investigate anomalies immediately
Follow up on any change that looks out of place, like a discount applied outside normal hours.
Catching an issue early is far cheaper than discovering it during a formal review months later.
What good looks like
- Every meaningful change is tied to a specific person and time.
- Disputes about who changed a record get resolved with a log instead of guesswork.
- Sensitive fields have fewer people who can alter them.
- Unusual activity gets caught during routine review, not by accident.
Common mistakes
The ways this goes wrong in data, and what to do instead.
Letting the team share one login›
Every audit trail entry shows the same generic account instead of an actual person.
Do this instead: Give every team member an individual login before relying on any change history.
Turning on logging after an issue occurs›
The one change you actually needed to trace happened before tracking was enabled.
Do this instead: Enable activity logging on sensitive record types now, before you need it.
Never reviewing the history›
A suspicious change sits in the log for months without anyone noticing it.
Do this instead: Schedule a recurring review of change history on your most sensitive record types.
Frequently asked
6 questions about set up audit trails and change historyRelated guides
Pick the next thing to set up, or back up a step if something here assumed work you have not done yet.
Do this next
The natural follow-on tasks once this one is working.
People usually get here from
Guides that lead into this one, in case you skipped a step.
More in Data
Nearby tasks that share the same setup and vocabulary.
Was this guide helpful?
Tell us what worked and what didn't. It shapes what we rewrite next.
You didn't get into business to be in the tech business.
Managed Tech clients hand this to us. We build it, test it, maintain it, and add to it as the business changes, so nobody on your team has to become the person who knows how the system works.