Skip to main content

Read the activity log and export it

Purpose​

Find out who did what in the account, check whether the system's own messages went out, and take a copy away as a spreadsheet.

Who this is for​

Account administrators, and anyone holding account-log, campaign-log or communication permissions.

Where this lives​

Sidebar Activity Logs, titled System Activity Logs. It holds three things on one page: the audit trail, the notification pipeline, and the in-app notification inbox.

The audit trail​

The main table lists, newest first:

ColumnWhat it holds
TimestampWhen it happened
ActionCreate, update, delete, and so on
ActorWho did it — by name where the server could resolve one, with the raw id in the tooltip
Entity targetWhat they did it to, as an id
ChangesHow many fields changed. A count, not a diff: there is no before/after viewer to open

Three controls narrow it: a search box (Search by actor or entity id…, which also matches the actor's resolved name), an All actions dropdown listing the action types actually present, and an All entities dropdown listing the entity types. The count on the right reads "n events logged" and follows your filters.

The page loads the 100 most recent entries. The export is not limited to what is on screen — see below.

Export to CSV​

Choose Export CSV in the header.

  • The download honours the search term currently in the audit-log search box, so filter first if you want a subset.
  • It streams the full filtered set from the server, capped at 1000 rows — not the 100 the page is displaying.
  • The file is named from the server's own content-disposition header, falling back to activity_log_<accountId>.csv.
  • On success the page confirms "Exported activity log to CSV." Failures report the server's reason in the same place.

The All Actions dropdown filters the on-screen table only; it does not narrow the export. Use the search box for that.

The notification pipeline​

Below the audit table sit five counters — Pending backlog, Failed, Retried events, Total retries, Dead-lettered. A Campaign scope dropdown above the table narrows the notification pipeline to one campaign; it does not touch the audit table, which stays account-wide whatever is picked.

Notification Events lists the lifecycle notifications queued by campaign, assessment and registration activity: event, entity, actor, channel, status.

Two buttons in the page header, beside Export CSV, act on it:

  • Dispatch pending — pushes the queued backlog through now instead of waiting for the scheduled run.
  • Retry failed — re-attempts the ones that failed.

Dead-letter recovery​

Events that exhausted their retries appear in Dead-Letter Recovery with their last error. Tick the ones worth another attempt and re-queue them. Treat a growing dead-letter list as a signal to look at the underlying cause rather than as a queue to keep draining.

The in-app inbox​

In-App Notification Inbox lists notifications delivered inside the product, with read/unread tracking. Mark one read, or mark all read.

Limits and gotchas​

  • Retention is not configurable from the interface. There is no log-policy screen.
  • The actor is shown by name where the server could resolve one, with the raw id in the tooltip; the CSV carries both, as userId and actorName. Entity targets stay as ids in both.
  • A campaign's own log — reached from Logs in the campaign header — is titled Campaign Audit Trail and carries that campaign's audit table as well as its notification pipeline. What lives only here is the account-wide view: every campaign, and the account-level actions that belong to no campaign at all.