Team audit log

What gets recorded

When the audit log is on for a team, every interaction with the team's data writes a row. Categories:

• Views. Opening a team note or folder. Repeat views by the same person within five minutes collapse into one row, so a page refresh doesn't bury the signal.
• Mutations. Creating, editing, archiving, restoring, deleting, moving, favoriting, or exporting team content. Bulk operations on the notes page record one row per affected note.
• Access changes. Invites, accepted invitations, member removals, ownership transfers, public link toggles, and SCIM provisioning from an external IdP.
• Account-level. When a team member deletes their Hjarni account. When team-level AI instructions change.

Surfaces covered

The audit log captures activity across all ways someone can reach your data, not just the web app:

What's in a row

Each entry captures:

• When. To the second.
• Who. The actor's email, or "anonymous" for public-link readers, or "system" for SCIM operations.
• Action. A namespaced label like note.viewed, container.updated, team.member_removed.
• Target. The affected note or folder, with its full path snapshotted at the time of the event so the row stays readable even if the resource is later deleted.
• Source. One of the surfaces above.
• IP hash. A one-way hash of the visitor's IP. Useful for spotting an abusive public-link reader without storing raw addresses.
• Details. Action-specific metadata. Which attributes changed, where a note was moved from and to, who invited whom.

Who can see the log

Only the team owner. Team members see the disclosure banner that activity is being recorded but cannot read the log itself. This is deliberate. The audit log is a control surface for the data steward, not surveillance data for peers.

If ownership of a team transfers, the historical audit log follows the team to the new owner.

How to enable it

The audit log is an Enterprise feature, available on request alongside SAML SSO and SCIM provisioning. Email evert@hjarni.com and mention the team name to turn it on.

Once enabled:

• A disclosure banner appears on the team page for every member.
• The owner sees a View audit log link in that banner.
• Rows start being written immediately. Filter by action or by folder subtree on the audit log page.

Member disclosure

When the audit log is on, every team page carries a notice telling members that views, edits, and access changes on the team are recorded. This is not optional and not hideable per-member. Audit logging without disclosure would be surveillance; disclosed audit logging is a control.

The exact wording, copied from the live UI:

Limitations

Worth knowing up front:

• Personal accounts aren't audited. The audit log is a team-only feature by design. Personal brains stay outside it.
• MCP search results don't write per-hit view rows. A single search call from an AI assistant can surface a hundred notes; recording a hundred view rows per query would dwarf real reads. Searches are still captured as a single note.searched analytics event, but each surfaced note isn't individually logged.
• No automatic retention pruning yet. Audit log entries persist indefinitely. A retention policy is on the roadmap.
• No built-in CSV export. Reach out if you need entries dumped for a subject access request or for downstream compliance tooling.
• PII in metadata. When someone deletes their account, the audit row mirrored to the team owner carries the deleted email. The invitee's email is captured on team.invited rows. Both persist past the original record's deletion. Acceptable for an audit log; worth knowing if you have strict data-minimisation requirements.

Related