"Who did that, and when?" is one of those questions that comes up in every serious business application eventually. Sometimes the context is benign: an admin trying to understand why a user saw a particular thing, a manager retracing a workflow, a support engineer reproducing a reported issue. Sometimes the context is tense: a compliance audit asking who accessed a sensitive record, an incident review asking who authorized a particular change, a security investigation asking whether an account's activity matches its owner's expected behavior. In either situation, the answer has to be one query away — not a forensic reconstruction assembled from server logs by an engineer who happens to be available. That's what a first-class event log provides, and it's one of the newest additions to the platform.
A uniform event envelope is the foundation. Every event logged by the platform follows the same structure: an actor (the user or system that initiated the event), an action (what they did), a target (what they did it to), an outcome (succeeded, failed, partial), a timestamp, and enough context to make the event meaningful — the tenant, the session, the IP address where applicable, any relevant before/after state. That uniformity is what makes the log searchable and analyzable at scale: every event is shaped the same way, so queries and reports don't have to special-case each event type.
Authentication events are the first category logged. Sign-ins, sign-outs, failed sign-in attempts, password resets, SSO exchanges, magic-link issuance and consumption, session terminations — every interaction with the authentication system is captured. For the "who's been trying to sign in as this user" question that arises in any security investigation, the authentication events give the answer immediately. For compliance reporting that requires evidence of access patterns, the authentication events are the source.
Data events cover the object-level changes that happen during normal use. A record being created, updated, or deleted generates a data event with the before and after state captured. Property-level changes — where they occurred, who made them, what the previous value was — are recorded at a granularity that supports the "who changed this field" question without requiring a separate audit mechanism. The activity log article covers the per-record view of this same data; the event log is the cross-cutting view that lets queries span many records at once.
Automation events capture the runtime behavior of scheduled and triggered workflows. Every automation run logs its trigger, its outcome, its duration, any errors encountered, and the records it affected. For debugging automation issues — a rule that fired when it shouldn't have, a rule that didn't fire when it should have, a rule whose output is mysteriously wrong — the event log is where the investigation starts. The automations article covers the authoring surface; the event log is the observation surface.
Admin events capture the operations that change the tenant's configuration or user population. Role changes, user invitations, user blocks and unblocks, impersonation sessions, tenant-configuration updates, feature-flag changes — all logged with the admin responsible and the timestamp of the change. For the compliance question "who authorized this change to our permissions model," the admin events answer it. For operational questions like "when did we last adjust this setting," the same log serves.
Filter and search make the log navigable at scale. An active tenant can generate thousands or millions of events in a year; raw chronological listing isn't practical. The event log supports filtering by actor, action type, target type, time window, outcome, and context fields — so "all failed sign-in attempts from this IP in the last week" or "all automation errors on this type since Monday" are one-query answers. Full-text search across event context fields handles the open-ended cases where the filter dimensions don't quite fit.
Impersonation is always logged and visibly distinguished from real user activity. When a support staff member uses the impersonate-user action to sign in as a specific end-user, every event during that session carries an impersonation marker alongside the normal actor field. That means the log entries correctly attribute the actions to the underlying user (for record consistency) while making it clear that a support session was responsible (for audit clarity). The dual attribution is what keeps impersonation both useful and accountable.
Quick navigation to the affected object is a small feature with outsized day-to-day value. A log entry that says "user X updated record Y" includes a link that takes the viewer directly to record Y — to see its current state, to review its full history, to understand what happened next. For administrators and support staff investigating an issue, that one-click navigation from the event log to the object of interest is the difference between productive investigation and archaeological frustration.
Retention policy is configurable per tenant to match each organization's compliance requirements. Tenants in heavily-regulated industries can retain events for the legally-required period — often several years. Tenants without such requirements can choose shorter retention to keep the log size manageable. Either way, the platform enforces the policy automatically: events age out on the configured schedule without manual intervention, and the tenant's event log stays within the expected size envelope.
Export for audit is the companion capability for cases where events need to go somewhere other than the platform itself. A compliance officer can pull a filtered slice of the log as a download. An operator can configure ongoing export to an external log aggregation system for unified monitoring across systems. A forensic investigation can pull a preserved copy of events relevant to the incident. The export respects the same filter and search capabilities as the interactive view, so the slice that goes out is the slice that was intended.
Tenant isolation applies to the event log the same way it applies to every other platform feature. Events logged in tenant A are visible only to tenant A's administrators; there's no cross-tenant bleed. For platform operators with fleet-level observability needs, there's a separate operator-level view that spans tenants under controlled access; the tenant-level event log serves the tenant-level compliance story without exposing data sideways.
For admins responsible for their tenant's security posture, for auditors who need evidence that controls are functioning, for support engineers who need to diagnose user-reported issues, and for investigators who need to reconstruct what happened during a suspicious period, the event log is the feature that turns "let me check the logs" from a vague promise into a concrete, fast, well-structured answer. For the adjacent topics, the authentication article covers the sign-in events the log captures, the automations article covers the workflow runtime events, the multi-tenancy article covers how isolation applies to the log itself, and the roles and permissions article covers who can see event data within each tenant. The event log is how the platform stays observable — to the people who need to know, and in the format they can actually use.