Audit Logs

The audit log is the immutable record of what happened on your deployment: who changed what, when, and from where. This page is the deep reference for the diagnostics surfaces under Setup → Diagnostics. For the operator overview of logs, metrics, and request identity, see Observability.

These surfaces require the manage_platform_settings permission.

Reach for the audit log when you need to prove or investigate:

• permission-sensitive changes;
• settings and configuration changes;
• user and session activity;
• integration and automation activity;
• denied-access analysis.

Audit Logs

At Setup → Diagnostics → Audit Logs (sys_audit_log). The object is read-only and immutable — an append-only trail of platform events. You can filter, group, and inspect rows, but nothing can edit or delete them from Setup.

What each reader is served

Every row stays stored, but since ObjectStack 17.6 a reader is served a row about a record only if they can read that record themselves — the same object permissions, sharing and row-level security that decide whether they can open it. That excludes:

• every delete row, and every other row about a record that has since been deleted;
• sign-out rows, and sign-in rows whose session has since been removed;
• rows about records the reader cannot open.

Rows about no record — configuration changes, user-import runs, auth events that carry no session — are served under the ledger's own grant, as before.

The view_all_audit_log capability lifts this narrowing (ObjectStack 17.7): its holder is served the deletion and sign-out trail and the rows about records they cannot open. Platform administrators hold it by default; an organization administrator does not, so grant it explicitly to anyone else who must read the whole trail.

Field-level security still applies inside every row. old_value and new_value serve a field only to a reader who can read it unmasked, and filtering, sorting or grouping on them is refused (403) unless the filter names one object by equality (object_name) and you can read every field of it.

Preset views

The list opens with tabs that filter by action category. Every tab applies the rule above:

Columns and fields

The default columns are Timestamp, Action (a coloured pill — create / update / …), Object, Record ID, and Actor. The footer shows the total record count (e.g. 36 records).

Each row carries the full field set:

The Config view is the fastest way to answer "who changed this setting?" — it narrows the trail to configuration actions before you start reading rows.

Reading a change

For write actions, the interesting detail is the before/after. Open a row's ⋮ menu to expand old_value and new_value and see what changed on that record — every field you can read in full, and nothing else. The Object and Record ID columns tell you what was touched; old_value/new_value tell you how; actor, ip_address, and user_agent tell you who and from where.

For regulated environments, back the immutability up at the storage layer — make the table append-only at the database and define a retention policy.

Notification Events

At Setup → Diagnostics → Notification Events (sys_notification). This is the ingress log of the notification system — one row per emit(), written before any delivery decision. Use it to diagnose why a notification did or did not reach an inbox; the routing and materialization that follow are documented in Notifications.

Preset views are Recent and By Topic. Default columns: Topic (e.g. project.digest), Severity (an info/warn/… pill), Actor, Source Object, and Created At.

The dedup_key collapses duplicate emits, and payload carries the raw event context that templates render from. Because this log sits upstream of routing, a row here with no matching inbox message usually means the audience did not resolve to that user, or their preference muted the topic on that channel — check Notifications when a user reports a missing alert.

Downstream, each event is materialized into per-user inbox messages (sys_inbox_message) — the recipient's view lives under Notifications.

Sessions

At Setup → Diagnostics → Sessions. Sessions lists active and recent sign-in sessions, so you can investigate a user's activity or revoke access. Pair it with the Auth audit view when reviewing a sign-in incident.

Where to go next