Close introduces a 30-day Event Log for CRM changes

A visible history of record changes

Close announced its Event Log on 18 August 2026. The interface shows changes made by users, Workflows, integrations and API clients, with filters for date, lead, event type, action and user. Operators can inspect organization-wide activity or the history associated with an individual lead. The release includes both a readable detail view and a raw event view.

The log covers the preceding 30 days and is available on all Close plans. Access requires either Manage Organization or View All Leads permission. Close also points developers to its Event Log API and webhooks. These are useful boundaries for buyers: broad plan availability does not mean every employee can view the history, and a rolling history is not a permanent archive.

Sources: Close original release

What an event can establish

An event record can help establish which operation occurred and which actor or integration was involved. The Close API documentation provides the technical reference for retrieving events. That evidence supports an investigation; it does not by itself prove that the resulting business value was correct or that every connected system accepted it.

Consider a disputed opportunity value. The operator needs to distinguish a deliberate commercial correction from an integration replacing a newer value with an older one. A timestamp and actor narrow the investigation, but the team should still compare the previous amount, the accepted quote, the effective date and the destination record. The right conclusion may be that the integration behaved exactly as configured while the mapping was wrong.

Sources: Close Event Log API

Build a reconstruction before making a correction

For an actual incident, start with the affected lead or opportunity identifier and a bounded time window. Save the relevant event identifiers and the observed before-and-after values where available. Record which integration, workflow or person had authority to write the field. Keep observations separate from explanations until the source evidence supports the explanation.

Then reconstruct the downstream path. Ask whether the change altered a queue, sequence, forecast, report or customer handoff. If a report imported the value before someone corrected it, the CRM may look healthy while the reporting snapshot remains wrong. An investigation is therefore complete only when the team has checked each material consumer, not when the field has been restored on screen.

Make retention an explicit operating decision

Thirty days is enough to investigate many recent incidents, but a team reviewing quarterly discrepancies can reach beyond that window. Decide which events warrant a separate retained record, who can access that record and how long the business actually needs it. Avoid exporting everything indefinitely just because an API exists. A retained copy should have a defined purpose and a controlled audience.

If events feed an external review process, design for continuity. Track a checkpoint, identify duplicate deliveries, monitor ingestion gaps and make reconciliation possible after an interruption. These are integration acceptance criteria to test against the actual API and webhook configuration. They should not be assumed from the presence of an Event Log button. Test recovery before the first important incident.

A useful evaluation for RevOps

Run a small, approved exercise using a test lead. Make one manual field change, one workflow-driven change and one change through the integration being evaluated. Ask an operator who did not perform the changes to reconstruct the sequence. Note what can be proven from the log, which details need another system and how long the investigation takes.

Include a change that should not proceed, such as an update by a user without the intended authority in a test environment. Establish whether the evidence explains the rejection as clearly as a successful write. Do not grant broad permissions to the entire revenue team simply to make the exercise easier. A designated investigator may need wider visibility than a normal seller.

Where the feature fits

The Event Log is most relevant when a small revenue team has enough automation that ownership of individual changes has become difficult to explain. It gives Close users a starting point inside their CRM rather than requiring every investigation to begin with a support request or an external integration log. It does not remove the need to document field ownership.

For a buying decision, compare the incident the team needs to resolve with the evidence available in its present stack. A reliable record trail, an accountable reviewer and a tested correction process are more useful than an unused archive. Measure successful reconstructions and unresolved cases over a representative operating period; avoid treating the volume of recorded events as a quality score.