Review the data audit log

The Audit Log is the per-record change history for your domain data — who changed what, and when. Open it to see the field-by-field history of a Site, Sample, or Lab Report, to confirm an edit, or to find when a record was deleted.

This is not the operational record of sign-ins and configuration changes. That is the separate Administration System Audit Log, which is Administrator-only and lives in a different database — see the comparison below and View the system audit log.

Before you start

• Role required: an internal user (Administrator, Data Manager, Manager, or Staff). The Audit Log is part of the Activity Hub, which requires an internal role.
• What you see: entries scoped to the Sites and Projects you can access. Administrators see everything. Choosing Sites or Projects outside your access returns no rows.

What the Audit Log captures

Erde writes an audit row automatically whenever a domain record is changed or deleted. Creating a record is not logged on its own — the record's first audit row appears when someone next edits it. Some bulk operations write a single summary row instead of one row per affected record, so a validation run over many results does not flood the log. A multi-select delete, by contrast, writes one Deleted row per record removed — you chose each row, so each is recorded on its own.

Each row carries one of four Action values, and the Changes it shows depends on the action: an edit shows the before and after value of every field that changed, while a deletion shows a snapshot of the record's final state.

Logger readings are the one exception

Individual logger readings — the high-frequency time-series points a datalogger records — are not audit-logged. They are bulk-ingested machine telemetry, so adding, editing, or removing a reading produces no audit row. The Logger Stream and its channels are audited like any other record; only the readings themselves are not.

Steps

1. Go to Activity Hub → Audit Log (/activity-hub/audit-log). The page opens to the most recent entries, newest first.

2. Read the grid. Each row is one logged change with these columns:

   Column	What it shows
   Time	When the change occurred
   Action	Modified, Deleted, Validation batch, or Validation cleared
   User	Who made the change (display name at the time, falling back to the user ID)
   Site	The Site the record belongs to, or — when the record has no Site scope
   Project	The Project the record belongs to, or — when the record has no Project scope
   Entity	The record's type; for a nested record, the parent record's name follows as in <parent>
   Identifier	The record's identifying code or name
   Changes	For Modified, each changed field as old → new; for Deleted, a snapshot of the record's final state

3. Read a Changes cell to see exactly what moved. When a Modified entry's changed field references another record — a foreign key such as LocationId — the cell shows the referenced record's name rather than its raw identifier.

4. A Deleted entry's snapshot goes a step further: each referenced record is captured as Name (#Id) — for example, Location: MW-02 (#2) or Equipment: Solinst Model 102 (WLM-001) (#1). The #Id is the record's internal identifier, recorded alongside the name so the deleted entry can always be traced to the exact referenced record — even if that record is later renamed or itself deleted, and even though the name shown was the name at the time of deletion.

5. Select a row to open that record's activity timeline — its full change-and-comment history — in a side panel. From there, Go to page opens the record itself.

Deleted records

A Deleted row still opens the timeline, which keeps the record's history — including the deletion snapshot — even though the record itself is gone. Because there is no longer a page to open, the timeline's Go to page button does not appear for a deleted record. The same is true on the dashboard's Recent activity feed: selecting an entry for a deleted record opens its timeline rather than a not-found page.

Filter the log

The grid pages through the full history on the server, newest first — there is no row cap. Paging, sorting, searching, and column filtering all run server-side, so they apply to the whole log rather than one loaded page. Use the toolbar page-size selector to change how many rows load at a time.

Two filter layers work together:

• The Filters dialog (below) scopes the whole feed by Site, Project, date range, author, entity type, and action. These are the shared Activity Hub filters — they carry across to Comments.
• Each column's filter dropdown and the toolbar search box narrow the list further. They run on the server across every entry you can access, and combine with the Filters dialog settings above.

Export (XLSX or CSV from the toolbar) covers every row matching the current filters and search — not just the page on screen. The grid shows Time in your local time zone; the exported Time (UTC) column is in UTC, so the file reads consistently wherever it is opened. A very large Excel export is capped at 100,000 rows; export to CSV to include every matching row.

1. Select Filters in the grid toolbar. The Filter Audit Log dialog opens.

2. Set any of these criteria:

   Field	What to enter
   Site	One or more Sites to scope to
   Project	One or more Projects to scope to
   From / To	The start and end of a date range
   User	One author from the people who appear in your accessible history
   Entity type	One or more record types, such as Site or Lab Report
   Action	One action value — Modified, Deleted, Validation batch, or Validation cleared

3. Select Apply. Active filters appear as chips above the grid; remove one with its ×, or clear them all from the dialog.

Action values

Every row is one of four actions. Modified and Deleted are per-record; Validation batch and Validation cleared are the operation-level summary rows that stand in for many records at once.

Value	Meaning	Changes column shows
Modified	A record's fields were edited	Each changed field, old → new
Deleted	A record was removed	A snapshot of the record's final state
Validation batch	A bulk validation operation over many results	A summary of the operation
Validation cleared	A bulk un-validation that cleared validations from many results	A summary of the operation

How it differs from the System Audit Log

Erde keeps two separate audit logs. The data Audit Log on this page tracks changes to your domain data. The System Audit Log under Administration tracks operational and security events. They answer different questions and live in different databases.

	Data Audit Log (this page)	System Audit Log
Records	Changes to domain data — Sites, Samples, Lab Reports, and the rest	Sign-ins, account and role changes, settings, server start and shutdown
Where	Activity Hub → Audit Log	Administration → System Audit Log
Who can open it	Internal users, scoped to their Sites and Projects	Administrators only
Stored in	The Application database	The Platform database

For why the two logs are separate — and how change history attaches to a record's aggregate — see Aggregates, locking, and auditing. For the System Audit Log itself, see View the system audit log.

What each row records

Beyond the visible columns, every audit row stores the full context of the change. This is what backs the grid and the Identifier link.

Recorded	Detail
Timestamp	When the change happened
User	The user ID and the display name as it stood at the time
Action	One of the four action values above
Entity	The record's type, display name, and identifier
Parent entity	The parent record's type, name, and identifier, when the record is nested
Aggregate	The owning aggregate's type and identifier
Scope	The Site and Project the record belongs to
Change detail	The field-level diff for Modified, or a snapshot for Deleted and summary rows

Growth and retention

The Audit Log is append-only by design: an entry is written once and never updated, and the application has no feature for editing or pruning audit history. That immutability is what makes the log defensible as a change record — and it also means the log only grows. Every edit and every delete writes a row, so a busy multi-user deployment accumulates millions of entries per year.

The audit tables live in the Application database, so your regular backups already cover them — include them when you monitor database size and plan backup storage. Where your retention obligations allow it, archiving old entries is a database-administration operation — export the rows, then delete by date range, directly against the database — not something you do from the application.

Result

You see your domain-data changes newest first, scoped to the Sites and Projects you can access. Each row names the actor, the action, and the affected record; the Changes cell shows the field-level edit or the deletion snapshot, and selecting a row opens that record's activity timeline — with a Go to page jump to the record itself, except where the record has been deleted.

Troubleshooting

Symptom	Cause	Resolution
The Audit Log does not appear under Activity Hub	Your account is not an internal user	The Activity Hub is for internal roles; sign in with an Administrator, Data Manager, Manager, or Staff account
You filtered to a Site or Project but got no rows	That Site or Project is outside your access	You only see entries for the Sites and Projects you can access; ask an Administrator about your scope
You can't find a record's creation	Creation is not logged on its own	The first audit row appears when the record is next edited; look for the earliest Modified row
An Excel export says it was capped at 100,000 rows	The XLSX format is built in memory and capped to keep the file manageable	Export to CSV instead — it streams every matching row with no cap

Related

• Activity timeline
• Activity Hub overview
• View the system audit log
• Aggregates, locking, and auditing