The audit log

What changed, and who changed it?

Audit logs (/audit-logs). The line under the title is accurate: “Every recorded change in your tenant, newest first.”

Tenant admins and auditors. A manager is refused: “Audit logs needs the tenant admin or auditor role.”

The verb badge is worked out from the last word of the action name, so a delete is red at a glance. Expand any row for the before-and-after pair, which is what people actually come here for.

What a row holds

Part	What it is
Action	A dotted name — employee.update, project.delete, screenshot.upload
Verb	A badge worked out from the last word. Red for delete, green for create
Actor	Who did it, or “system”
Entity	The kind of thing and the first part of its id
IP and time	Where from, and when

Expand a row and you get three more things: a Before panel, an After panel, and the browser the change came from. A panel reads — where there was nothing — a create has no before, a delete has no after.

Answering “who changed this”

1. Put the thing in Entity type — project, employee, tenant_settings.
2. Set the Audit window to the period in question.
3. Pick the person in the Actor list if you already suspect one.
4. Press Apply, then expand the row and read Before against After.

The search box only searches the page you are looking at

It filters the 50 rows already on screen, over the action, entity type, actor and IP. It does not reach the server.

So a search that finds nothing has told you nothing about last month. Use the filter fields, not the search, when the answer could be older — then page through.

Three of the four tiles count this page only

Today, Deletions and Actors are counted across the rows currently loaded — their hints say so: “Among the rows on this page.”

Only Total counts every entry matching your filters across all pages. Reading “Deletions: 2” as “there were two deletions” is wrong unless there is only one page.

What it does record

• Configuration changes, with before and after
• People created, invited, updated, deactivated
• Projects and tasks created, changed, deleted
• Timesheet decisions
• Screenshots uploaded and deleted
• A manager or admin requesting an on-demand screenshot, with both names

What it does not record

Say these before a compliance review, because the question comes up.

Nobody’s viewing is recorded

Reading a report, opening a screenshot, exporting a file — none of them produce a row. The log is a record of changes, not of access.

“Who looked at this person’s screenshots?” has no answer in this product. Neither you nor an auditor can produce one.

Failed attempts. There is no denied or refused outcome in the table. A blocked action leaves nothing behind, so a person probing for access they do not have is invisible here.

Severity. Every row is equal. Deleting every project and renaming one look the same until you read them. There is no filter for “important”.

Two things the screen itself cannot do

There is no export button on this screen

There is no download action on the page and no audit-log report type on the Exports screen either — the seven report types it offers are all about time and activity.

To hand the log to somebody you copy from the table, page by page, or ask for a database export. For a regulator who wants twelve months, plan for the second one.

Paging is 50 rows at a time with Previous and Next, and no jump. A long investigation is a lot of Next. Narrow with the fields first.

How long it is kept

The nightly retention job deletes screenshots, activity, app records, idle events and integrity checks. Audit logs are not in that list. They are kept for the life of the workspace.

That is the right way round: the record of who changed the policy outlives the data the policy governed.

Next: What an auditor can see · Workspace settings