Audit log — who did what, when

The audit log is the answer to "who did what, when?" — every admin-side action that mutates state is recorded with the actor, the target, the timestamp, and a JSON metadata blob. Use it to investigate a misconfiguration after the fact, to satisfy a regulator who needs proof of access controls, or to track what an automation did overnight.

What's recorded

A non-exhaustive list of action categories that land in the log:

  • Tool — created, edited, enabled, deleted.
  • Document — uploaded, deleted, re-embedded.
  • Conversation — viewed (sometimes; per privacy mode), handed off, resolved.
  • Snippet / knowledge — created, edited, deleted; merge-proposal decisions.
  • Team — invites sent, accepted, members removed, permissions changed.
  • Settings — SSO config saved, allowed-domain changes, retention changes, billing actions.
  • Compliance — DPA requested, signed, subprocessor acknowledged.

Read-only browsing (looking at the leads list, opening a settings page) is not logged. The log is for state changes only.

Filtering the log

The filter bar lets you narrow by:

  • Action — pick from a curated dropdown (tool.created, document.uploaded, etc.). The list is fixed; you can't search for ad-hoc patterns.
  • Entity type — tool, document, conversation, etc.
  • Date range — last 7 / 30 / 90 days, or custom range.
  • Free-text — searches the actor email and the JSON metadata.

The page shows 50 entries at a time; pagination at the bottom.

What's in each row

  • When — exact timestamp, in your local time.
  • Actor — the email of the person (or service) who did the action. SSO-provisioned members appear with their IdP-asserted email. System actions (cron jobs, automated cleanups) appear as system.
  • Action — noun.verb style; tool.created, team.removed, compliance.dpa.signed.
  • Entity — what was acted on. Usually a name or id; click into the row for the raw JSON.
  • Metadata — additional context (before/after values, which field changed, IP for some auth events). Some historical entries have empty metadata; we've been gradually filling it in.

Export to CSV

The Export CSV button (when enabled on your workspace) dumps the currently-filtered view to a CSV. Useful for:

  • Sharing with your auditor or security team.
  • Importing into a spreadsheet for ad-hoc analysis.
  • Long-term retention beyond what we keep on the page.

If the export button isn't visible, the feature isn't on for your workspace — email us to enable.

Retention

Log retention depends on your plan. The page surfaces a retention note at the top — anything older than that window has been purged. If you need longer retention than your plan provides, export periodically (or talk to us about a higher retention plan).

Common questions

  • Who can see the audit log? Currently any member can read it. Sensitive metadata (passwords, secrets) is never logged in the first place.
  • Where do I see who signed in? Authentication events appear in the log under auth.* actions. Filter by entity = auth.
  • Where do I see SSO sign-ins? Same place — auth.sso_login entries. The actor is the IdP-asserted email.
  • Can I export beyond the displayed window? Only what's in the current filter. Filter by your desired date range first, then export.
  • Why doesn't action X appear? Either it's a read-only browse (not logged by design) or it's a recent feature where metadata is still being filled in. If you think a write was missed, file a bug.
  • How long is the log kept? Plan-dependent; the page shows the current window at the top.
  • What's a system actor? A scheduled job or an automated cleanup did the action — no human pressed a button. E.g. retention purge, webhook retry.

See also team for permissions, compliance for DPA actions in the log, and SSO for SSO-mediated logins.

Where to find us

Stuck? Email [email protected]. If you need the audit-log CSV export turned on, mention that.