Activity reports

The platform keeps a log of what happens to records: specimens and sequences added or changed, evidence files attached or suppressed, records moved between projects or added to datasets. Once an hour that log is summarised into an activity report, and it is the report, not the raw log, that the workbench shows. This page explains where the activity you see comes from, which events are in it, where it appears and how far behind real time it runs, so you can answer "why does the activity card not show what I just did?"

How it works

Every write to the record store is recorded in the store's activity log as one entry: the time, the type of object, the event, who did it and which records (by Process ID) it touched. Recordset events also carry the code of the project or dataset concerned.

An hourly job reads the new log entries since its last run and writes activity report rows. Each report row belongs to one recordset and one log entry, and carries the event type, the actor, the number of records involved and the recordset code. An entry whose records belong to several projects produces one report row per project, so a single upload across two projects appears in both projects' activity. The hourly run processes up to 10,000 log entries at a time and either commits the whole batch or none of it, so a failed run is simply repeated next hour from the same point.

What is recorded

Events are attributed to the project a record belongs to when the hourly job runs, except for the move and dataset events, which carry their target recordset explicitly. Suppressed evidence is hidden, not deleted: the activity report records the suppression, and the underlying file remains in the file store.

Good to know: the log records what happens to records and their evidence. It does not record sign-ins, searches, downloads, analysis runs or statement activity. Those are not activity events and do not appear in any activity card.

Where you see it

• A user's HQ. Opening a username from the Users page shows that user's HQ, with an "Activity in Last N Days" card listing the timestamp, the actor, the object type, the event with its record count, and the recordset. It covers events in the projects and datasets that user belongs to over the last 365 days, which is to say the activity they can see, not only the actions they performed. The actor column tells you who did each thing.
• A recordset's console. Each project and dataset page has an Activity Report card, collapsed by default, with the same events for that recordset and quick filters for the last day, week, month or all time.
• Your own HQ shows the same card for your own recordsets. Administrators see their own recordsets there, not everyone's; use the user's HQ or the recordset console to look at others.

How fresh it is

Activity is summarised on the hour, so an event appears in the cards up to an hour after it happened, never sooner. If a card is empty for something a user did a few minutes ago, that is expected; look again after the next hour. When a very large load lands at once, more than 10,000 log entries in an hour, the backlog is worked through 10,000 entries per run, and the latest events wait until the earlier ones have been summarised.

The activity log itself is written immediately. Only the summary that the workbench reads is delayed.

Good to know

• Activity reports are per recordset. A record that belongs to no project at the time the hourly job runs produces no report row for that event.
• Counts in the Event column are record counts for that log entry, not file counts. One upload of 40 images to 10 records is "New-Images (10)".
• The activity cards are a monitoring view, not a signed audit trail. For evidence of who did what to a specific record for legal purposes, rely on your institution's chain-of-custody procedures alongside the platform.

Related

• Managing accounts
• Overseeing projects and datasets
• Access, logging and retention