Skip to content

The activity feed and audit log

The activity feed is the human-readable view of the platform's audit log — a running record of who did what to which record, and when. It appears as a standalone page (with type and date filters) and as the embedded activity panel on deals, companies, contacts, and other records.

What gets logged

Almost every action logs an audit entry, driven by an annotation on the action (there are over 200 of them) — viewing an agreement, updating a deal, downloading a document, saving a company, and so on. Each entry records:

  • Who — the actor's name, company, and contact.
  • What — the action title (e.g. "Update Agreement", "Download Agreement PDF") and its type (view / save / edit / delete).
  • Which — the entity acted on (type, ID, name) and its parent (e.g. a document's deal), resolved into a readable context.
  • When and from where — timestamp and IP address.

Entries are stored in daily search indices (.audit-…); there is no separate database table for the feed. Staff on the internal ebiz role are not logged, so they don't appear as actors.

The feed vs the raw log

The activity feed deliberately excludes plain page-views and turnover-flag noise, so it shows meaningful changes rather than every click. A separate admin audit-trail search exposes the full log (including views) with charts and per-user/company breakdowns.

Filtering

  • Standalone feed — filter by action type (chips with live counts from the log) and by date preset, plus free-text search over actor, action, and entity name.
  • Embedded feed — scoped to one record: it shows actions on that record and on its children (e.g. a company's contacts, a deal's documents). For a contact it also shows actions the contact performed.

Who can see it

Viewing the feed requires a logged-in user with the base view permission. Crucially, the feed is scoped only by site — it is not filtered by what you're allowed to see: any authenticated user of a site sees the audit activity for all of that site's records, not just the ones they have permission on.

The per-user activity report

A per-user activity report summarizes one contact's behavior over a window: deals viewed, documents downloaded (with names), daily/hourly activity, IP addresses, out-of-hours and error counts, and any security alerts raised. It is the same analysis the suspicious-activity monitor uses.

This report endpoint is public (whitelisted) and its permission check is commented out — so anyone who knows the URL can pull any contact's full activity report.

Relationship to suspicious-activity monitoring

The same audit data feeds the suspicious-activity monitor, which compares each user's recent volume against their own baseline and flags anomalies (and separately detects bot-like access patterns). Its alerts are written back as audit entries, so they show up in the feed too. The monitor's thresholds are configured in site settings.

Retention

Audit entries are kept in daily indices and read across all of them, so the feed and reports see as far back as those indices exist.

Why does the feed look incomplete

  • A page-view isn't there — pure views are excluded from the feed by design (use the admin audit search for those).
  • A staff action isn't there — internal ebiz-role users aren't logged.
  • An entity feed is empty — nothing loggable has happened to that record yet, or its actions logged without the entity context resolved.

What the activity feed is not

  • Not the news feed — news posts are a separate feature (News posts).
  • Not notifications — the in-app notification system is separate.
  • Not a permission boundary — it shows site-wide activity regardless of record permissions (see above).