Skip to main content

Activity feed

Organization → Activity is the audit-event log scoped to one organization: every recorded mutating action whose target belongs to this org, newest first. It is the same store as the cross-org Platform → Audit log, filtered to your org, and it is append-only — the product only ever inserts rows, and on PostgreSQL a database trigger refuses updates and deletes (see Security model → Audit log).

Visible to org Owners and Admins (and platform staff); the tab is hidden and the route refused for other roles.

What lands here​

An event is attached to an organization when the action passes one explicitly or when its target has an organization (a project, a membership, a payout run…). Each row records:

FieldMeaning
ActionA slug such as member.add or org.payout_run_paid, humanised in the feed (Member Add)
ActorWho did it — name or email; System when there was no signed-in actor. The email is snapshotted at event time, so it survives the user's deletion
TargetA human label for the affected object (a title, email, or name)
WhenRelative in the list, exact in the detail
MetadataAction-specific key/values (e.g. from_role, to_role, run_id, total)

Rows are colour-coded by kind: created/added/granted, changed, removed/ suspended/revoked, or neutral.

Event catalogue​

The action filter lists the catalogued actions: user lifecycle (created, activated / deactivated, deleted, staff granted / revoked, password set, passkey added / removed / sign-in, HF token set / cleared, signup and device-link consents, speaker-demographics consent), organization lifecycle (created, updated, deleted, ownership transferred), org membership (invited, added, removed, role changed, suspended / unsuspended), project lifecycle (created, deleted), project membership (added, removed, role changed), contribution rate-card updated, and platform branding updated.

Changes say what changed. A role change carries the role as it was and as it is (from_role, to_role), in the organisation and in a project. A save of the organisation's policies carries changes: each policy that changed, with its value before and after and "(enforced)" where it applies. Long values are recorded by their length, and anything that looks like a secret as "(hidden)".

Other org-scoped actions are logged with their own slugs and appear in the feed and in search even though they are not in the dropdown — for example payout runs (org.payout_run_created / _paid / _deleted), receipt templates, auto-suspend rules, rate-change acknowledgements, consent require / sign / withdraw, review accept and dispute, and project-member pause / resume. Filter those with the search box rather than the dropdown.

Filters​

  • Date range (title row): 7 days, 30 days (default), 90 days, 1 year, All time, or a custom from–to.
  • Search: case-insensitive substring match on the actor's email or the target label — not on metadata or action slugs.
  • Action: one catalogued action at a time.

The count next to the filters is the total matching events; 25 per page by default (10 / 25 / 50 / 100). Changing any filter returns to page 1.

Detail view​

Click a row for Who (linked to the actor's profile when they still exist, with email), What (action + target), When (exact timestamp + relative), every metadata key as its own line, and the Event ID.

What it does not do​

  • No export. Unlike the platform audit log, the org feed has no CSV download; page through it or use the API (/api/organizations/<id>/activity, up to 200 rows per page, same filters plus actor=<user id>).
  • No retention setting — events are kept indefinitely; nothing in the product updates or deletes them.
  • Not every change is an event. Annotation submissions, task imports, storage connections, and webhook deliveries are not audit events; use Metrics for volume and the project's own pages for those.

Gotchas​

  • "System" actor means the request had no authenticated user (a background job or an unauthenticated flow), not that data is missing.
  • Search the email, not the name. Actor search matches the snapshotted email; the display name is resolved live for the row only.
  • Deleted users keep their footprint — the actor email stays on every row they produced.

What's next​