Audit Log
An audit log is a time-stamped record of the actions people and automated processes take in a system, showing who did each one, what they did and when. A CRM audit log covers events such as logins, changes to user roles and permissions, edits to settings, and actions on records, such as imports, merges and deletions, whether they happen in the CRM or in a tool connected to it.
An audit log answers a question other histories leave open: who. A record's change history shows how its values moved over time, and a merge history shows what each merge combined, but the audit log ties each action to a person or process and a moment. That makes it the place to look when a team needs to explain a change, review who has access or show how the system is used.
See how Dedupely keeps a record of who merged what in your CRM
What Is an Audit Log?
An audit log, also called an audit trail or activity log, is the running list of events in a system, written as they happen. Each entry names the user or process, the date and time, and what was done. Some entries are about the account, such as a login, a failed two-factor attempt or a new admin. Others are about the data, such as a bulk update, an import or a merge.
A short example: on a Tuesday afternoon, the owner of the Acme contact J. Smith changes from Dana to Lee, and an hour later J. Smith is merged with a second J. Smith record. The record's change history shows the old and new owner. The audit log adds who made each change, at what time, and that the merge ran as part of a scheduled job rather than by hand.
The events can touch each object a team works with, from HubSpot companies and Salesforce leads to Pipedrive organizations and Close opportunities.
There are a few kinds of logs, and each answers a different question. A system-wide audit log covers account and security events in one place, which suits access reviews. A per-record change history, sometimes called field history, shows how values changed on one record, in context. Tool-level logs, kept by each app that writes to the CRM, such as an integration or a deduplication tool, show in detail what that tool did. Many teams rely on more than one.
How an Audit Log Works
A CRM audit log follows a simple cycle, from the moment an action happens to the moment someone looks it up:
- Capture the event. Each tracked action, such as a login, a role change, a settings edit, a scan or a merge, creates an entry when it happens. Scheduled and background jobs are logged too, so automated work can be traced as well as a click.
- Record who, what and when. The entry stores the user or process, the date and time and a short description. A detail view can add context, such as the setting or object affected.
- Limit who can read it. The log shows logins, security events and how each person uses the system, so access is often limited to admins or the people responsible for the account.
- Keep entries over time. Retention varies: some systems keep entries indefinitely, and others keep them for a set period, after which older events can only be found in an export.
- Search and filter. Filters by date range, user or description text narrow the log to one event, one person's actions or everything that happened during a cleanup.
- Read it alongside the other histories. The audit log points to who acted and when. The record's change history or the merge history then shows exactly which values changed, so a team can trace a change from start to finish.
Why an Audit Log Matters for CRM Teams
CRM data changes for many reasons at once: reps edit records, integrations sync new values, imports add rows, and scheduled jobs merge duplicates. When a report shifts overnight or a key account loses its owner, the first question is what happened, and the audit log narrows it to a person, a process and a time. Without one, tracing a change means asking around, comparing old exports and guessing which tool was involved. With one, the same question often takes a few minutes with a filtered list of entries.
It also keeps automation accountable. A scheduled merge or a changed matching rule can affect many records in one run, and a log entry shows when that run happened and who set it up, so the records it touched can be found and checked. That matters for reporting, since merged or edited records change contact counts, pipeline totals and campaign attribution.
Access is the other half. Logins, failed two-factor attempts, new users and role changes show who can reach customer data, and whether that matches who should. A log that records these events supports security reviews, offboarding checks and the questions that come with a compliance review, without relying on anyone's memory of what changed.
Getting Started With an Audit Log
Start by listing the systems that change your CRM data: the CRM itself, integrations, import tools and any deduplication tool. Check what each one logs, who can open the log and how long entries are kept. A change made by a connected tool often shows up only in that tool's log, so knowing where each log lives saves time later.
Decide who can read each log and keep that group small, often the admins responsible for the account. Review the log on a routine and at set moments: after a large cleanup or import, when someone joins or leaves, and when roles or security settings change. Look for unexpected logins, failed two-factor attempts and changes made outside normal hours.
When something changes without explanation, start with the log rather than a guess. Filter by date, then by user, to find the action and who ran it. Then open the record's change history or the merge history to see which values changed, and fix the setting or rule that caused it.
In Dedupely, the Audit Log sits under Company Settings, open only to admins, and records merges, including background merges, along with scans, scheduled Auto Matches, Duplicate Search changes, user invites and role changes, logins and logouts, two-factor attempts and security setting changes. You can filter it by date, user and description, and while Merge History shows what each merge changed, the Audit Log shows who ran it and when.
Key Takeaways: Audit Log
An audit log is the time-stamped record of who did what in a system and when, covering account events such as logins and role changes as well as actions on data, such as imports and merges. It answers who acted, while change history and merge history show what changed, so teams often read them together. A useful log captures scheduled and background jobs, is limited to admins and can be filtered by date and user. In Dedupely, the Audit Log is admin-only, under Company Settings. It records merges, including background merges, scans, Duplicate Search changes, invites, role changes, logins and security setting changes, keeps entries indefinitely and filters by date, user and description. Merge History shows what each merge changed.
Frequently Asked Questions About Audit Logs
Can you see who changed or merged a record in a CRM such as Salesforce or HubSpot?
Yes, if the system that made the change logs it, and the audit log is where to look. Start with the CRM's own history for the record, which in some CRMs shows changed values and sometimes the user. If the change came from a connected tool, such as an integration, an import tool or a deduplication tool, the CRM may only show the tool's connection as the actor, so the person behind it is in that tool's own log. Check each system that can write to the CRM, then match the time of the change across them. In Dedupely, who ran a merge is recorded in the Audit Log, which only admins can open. Each entry shows the user, the date and time and a description, and merges are logged, including background merges. Merge History then shows what was merged: each original record and its values. Together they show who merged a record, when, and what it looked like before.
What should a CRM audit log record?
A CRM audit log should record every action that changes access, settings or data, with who did it and when. On the access side, that means logins and logouts, failed and successful two-factor attempts, new users, role changes and changes to security settings. On the data side, it means imports, bulk updates, merges, deletions and changes to the rules that drive automated work, such as matching criteria or schedules. Scheduled and background jobs belong in the log too, since they can change many records without anyone clicking. Each entry needs a user or process, a timestamp and a clear description. In Dedupely, the Audit Log records merges, including background merges, scans, scheduled Auto Matches, Duplicate Search changes, user invites and role changes, logins and logouts, two-factor attempts and security setting changes. Each entry shows the user, the date and time and a description, with a detail view for more context.
Who should be able to see an audit log?
Only the people responsible for the account, often admins, should be able to see an audit log. The log shows how each person uses the system, when they sign in and which security events happened, so it's sensitive in its own right. A small group of readers also keeps the log useful as an independent record: the people who review it aren't relying on everyone who appears in it. For a sales team, that often means the CRM admin and the operations or security lead, with entries shared as needed during a review. When roles change, check who can still open the log. In Dedupely, the Audit Log is part of Company Settings, which only admins can open. There are two roles: Admin, with access to everything including Company Settings, and User, with every feature except Company Settings. Only admins can invite users or change roles, and those changes appear in the Audit Log.
How long are audit log entries kept?
It depends on the system: some keep audit log entries indefinitely, and others keep them for a set period before older events are removed. Check the retention for each system that changes your CRM data, including the CRM itself and every connected tool, since the shortest one limits how far back you can trace a change. If a log keeps entries for a limited time and your team needs a longer record, for security reviews or compliance questions, export the entries on a regular routine and store them with the account's other records. Retention also matters when a problem surfaces late, such as a wrong merge found months afterward. In Dedupely, Audit Log entries are kept indefinitely, so merges, scans, Duplicate Search changes, logins and security setting changes stay on record. Admins can filter the log by date, user and description to find older events.
How is an audit log different from a CRM audit?
An audit log is an ongoing record of who did what in a system, while a CRM audit is a review of the CRM's data and setup at a point in time. The log is written continuously, entry by entry, as people and processes act. An audit is a project: a team checks duplicates, missing values, unused fields, ownership and the integrations that create records, then decides what to fix. The two support each other. During a CRM audit, the log helps explain how the data reached its current state, such as which import or rule changed a set of records. After the audit, it shows whether the fixes held and who made later changes. In Dedupely, the Audit Log covers actions taken in Dedupely, such as merges, scans and Duplicate Search changes, while Duplicate Searches help with the duplicate check in a CRM audit, and Merge History shows what each merge changed.
