"Who changed this, and when?" is the question every business asks eventually — usually after a small mistake has produced a larger consequence. A customer's phone number is suddenly wrong; an invoice's amount doesn't match the contract; an approval was toggled by someone who shouldn't have had the permission. Finding the answer quickly is what separates a small correction from a long, uncomfortable investigation. An activity log built into the platform means implementers don't have to think about audit trails at all — they happen automatically, for every record of every type, from the first day a tenant goes live.
The capture is automatic and comprehensive. Every create, update, and delete on any type produces a log entry. Entries carry the author, the timestamp, the action, and — for updates — the per-field diff: which properties changed, what the old values were, what the new values are. "Record updated" alone would be nearly useless for investigation. "Status changed from Pending to Approved by the regional director at 14:02" is what users actually need.
Every record carries its own activity tab with its history in context. Open a record, click the tab, and you see its entire change history in chronological order, with diffs on every update. That's usually where most investigation begins. The user has the record open anyway; the history is one click away; they don't have to hunt through a separate log to reconstruct what happened.
Above the individual record, a central activity log provides a cross-cutting view across the tenant. Filter by user, by type, by action, by date range, and you get a timeline of what was done, by whom, to what. That's the surface that answers questions like "show me everything a specific user did yesterday," or "show me every change to Invoice records this month," or "show me every deletion across the whole tenant in the last quarter." The underlying data is the same as on the per-record tab; the log is just a lens over it that aggregates rather than scopes.
Permissions apply to history the same way they apply to data. A user who can't see a record also can't see its history, and a user who can see a record but can't see a particular property sees the record's history with the property's changes filtered out. That's important in tenants with sensitive fields — a salary change that shouldn't be visible to non-managers is invisible in their activity view as well, not just on the record itself. The log is a surface of the same underlying authorization model, not a separate channel that bypasses it.
No-change suppression is a small but important detail. If a user opens a record, clicks save, and nothing actually changed — a surprisingly common event — nothing gets logged. That prevents the log from filling with noise and keeps diffs meaningful. When an entry exists, it means something changed; when nothing changed, the log is quiet. That simple rule is what makes the log readable a year later.
Linked context makes individual entries actionable. A log entry for "customer phone number updated" links back to the customer record; a log entry for "invoice amount changed" links to the invoice and, often, to the related customer or order for broader context. Navigating from a question to the affected record is a single click. Investigations that might otherwise require cross-referencing two or three places collapse into a short series of clicks through the log.
Integration with mentions closes a collaboration loop. An @ mention inside a rich-text field — on a comment, in a description, in any rich-text property — registers as an activity that not only appears in the log but also triggers a notification to the mentioned user. The log captures the fact that someone was mentioned, by whom, and in what context. Teams get both the visible acknowledgment (a notification lands for the mentioned user) and the audit trail (anyone looking later can see who tagged whom).
Through the REST API, the activity log is queryable the same way any other type is. External systems can subscribe to the log for compliance archiving, for security monitoring, for business analytics — whatever the downstream need happens to be. Pair that with webhooks and you can push activity events in real time to a SIEM, a data warehouse, or a Slack channel. The log isn't locked inside the platform; it's an addressable dataset like any other.
Performance at scale matters for this feature in a way it doesn't for most others, because a busy tenant produces a lot of activity. The logging layer is designed to absorb writes asynchronously where possible, so audit never becomes the bottleneck in a user's save. The central log scales to millions of entries with pagination, filtering, and sensible retention rules — and on the operator side, retention is configurable per tenant, which matters for regulatory environments with specific requirements.
For deeper auditing needs, the newer event log feature (covered in its own article) captures a broader set of events — sign-ins, automation runs, admin operations, system events — in a uniform envelope. The activity log remains the record-focused view; the event log is the system-wide view. Together, they cover both the forensic question ("what happened to this record?") and the operational one ("what happened in this tenant?").