Admin: Audit & activity

DraftMesh keeps an append-only record of what happened in your organization. Rows are added and never changed or deleted — the database itself refuses updates, deletes, and truncation of the table, so the record cannot be quietly edited even from behind the application.

⚙ Settings → Administration… → Audit log is where you read it.

What is recorded

Each row carries who acted, what they acted on, whether it succeeded or was denied, when, and a request id. Where an assistant acted using a person’s credential, the row names both. Where a task caused the act, the row names the task. Where the actor is a guest, the row says so in its type column, and a guest’s comment carries the name they typed and the same guest id the comment in the document carries — so the two can be matched. A guest merely opening a document is recorded against the link they used, not a person.

For the organization’s own acts the Result column tells you why something did not happen: a value starting denied: is a refusal DraftMesh made and an admin can act on (denied:last_admin, denied:already_accepted); one starting failed: means the identity provider did not complete the act and it is worth retrying (failed:upstream_unavailable).

Reading the log is itself in the log. “Who looked at everyone else’s activity” is exactly the question this record exists to answer. Paging through a long log does not add rows — only the first page of a listing does, so a reader scrolling to the end cannot inflate the very thing they are reading. Every export is recorded, every time: a copy of the record leaving the system is the single most important line in it.

Reading and filtering

Presets sit above the filter bar: Decisions narrows to sign-off requests and recorded approvals in one click. Add a From / To range to it and you have “everything approved this quarter” on one screen — and, with Export CSV, in one file.

The filter bar takes:

• Action starts with — a prefix, so doc. narrows to document activity, agent. to agents, share. to sharing. Typed characters are matched literally; wildcards are not a thing here.
• Principal — one person or agent.
• From / To — a date range.
• Result — Any result, Success, Denied — no grant for that one kind of refusal, or the broader Denied for every refusal however it arose.
• Task id — every row an agent task caused, from the id on the task.

Apply filters runs them and Clear puts the bar back. Results load newest first, with Load more for the next page.

Exporting

Export CSV downloads the log under the filters currently applied — the same rows you are looking at, unpaged. This is the artifact to attach to a security questionnaire or hand to an auditor.

Two things about the file are worth knowing:

• It is capped at 10,000 rows. If your filters matched more, the file ends with a line reading # truncated at 10000 rows — narrow your filters. That notice exists because a silently short file is how an access review reaches a confidently wrong answer.
• Text columns are neutralized against spreadsheet formulas. Names and document paths are written by members, so a cell beginning = is written back out as text rather than something Excel will evaluate.

The Access review section has its own export on the same terms.

Honest limits

State these plainly if someone asks:

• Retention is indefinite and not configurable. Nothing ages out, and there is no setting to make it. The record grows for as long as the account exists.
• Browser sign-ins are not recorded. A device pairing writes a row; signing in to the web app does not. Every refused request is recorded either way.
• A guest is only as identified as the name they typed. The name on a guest comment — or on a guest sign-off (guest.signoff_recorded) — is unverified, and a guest opening a document is recorded against the link, not a person — the log cannot tell one reader using a link four times from four readers using it once.
• Opening a document to read it is not individually recorded. Writes are — every save, restore, and merge. So are guest sessions, refused requests, and sync between devices. But a signed-in member reading a document they already have access to leaves no per-read row, so the log answers “who changed this and who was refused” fully, and “who looked at this” only partially. The log viewer carries a standing caution that successful document-read events may be sampled and read counts should be treated as a lower bound; take that as the ceiling on what this log will ever promise about reads, not as a hidden count you could go and find.
• Panel views are hidden by default. Opening the Share panel, the Groups list, the agent registry, or this log writes a row (share.list_viewed, group.list_viewed, agent.list_viewed, audit.viewed, admin.*.viewed) — a record that a list was shown, not that anything was done. Those rows are still written, but the viewer and the CSV leave them out unless you tick Show panel views, and the API leaves them out unless you pass includeViews=true. Guest opens, exports, and every grant, revocation and refusal are always shown.
• Some high-volume machine events are counters, not rows — webhook delivery retries, rejected agent callbacks, and subscription throttling are tracked as metrics. Recording each one would bury the acts that people actually performed.
• There is no streaming to an external SIEM. Getting the record out means the CSV export, run by an admin.
• The record is append-only, but not cryptographically tamper-evident. There is no hash chain over the rows — the guarantee comes from the database refusing to modify them, not from a signature you could verify independently.