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.

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

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, or a specific kind of denial (Denied — no grant, Denied — not owner).
• 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.
• 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.
• 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.