Understanding the Activity Feed

What you can expect

• Authentication events (sign in, sign out, failed attempts)
• Team events (invite, join, remove, leave, role change)
• Data events (downloads, delivery received, CSV exports)
• Settings events (industry changes, delivery config)
• Billing events (checkout completed, payment updated)
• Plain-English description, actor label, timestamp, and raw metadata per event
• Category filter and free-text search

Limits

• Individual events cannot be edited or deleted
• Retention is 365 days, older events are pruned
• No real-time notifications on events (no webhooks yet)
• Members cannot see other members' events, even with filters

How it works

Events are written through a single server-side helper that inserts into the shared audit_log table. The helper derives the event's category from the action name (the prefix before the first dot, e.g. "member.invited" → category "member") so filtering by category is a cheap index lookup.

Each event includes the actor's user ID (for member scoping), the organization ID (for cross-org isolation), and a JSON details blob with action-specific metadata. The IP address and user agent from the request are captured for context.

Row-level security on the database enforces the admin-vs-member scoping directly, even if an API route had a bug, the database would still refuse to return another member's events to a non-admin.

Common misconceptions

• "I can delete embarrassing events from the feed", false. The feed is insert-only and RLS blocks deletes from any client, including admin sessions.
• "Members can see each other's downloads", false. Members only see their own events.
• "The feed is permanent", false. Events older than 365 days are automatically pruned. Export to CSV regularly if you need longer retention.
• "The feed is real-time notification", false. It is a passive log. Nothing pushes notifications based on feed events.

What to do

• Review the feed weekly in your first month to confirm your team is using the portal as expected
• Export to CSV monthly for compliance documentation if your policies require it
• Use the category filter to narrow to just team events when you are investigating a membership question

Event categories at a glance

Every event name uses the form <category>.<verb>. The category is also indexed on its own so filtering is cheap:

• auth: login, logout, login_failed
• member: invited, joined, removed, left, role_changed
• data: downloaded, delivery_received, audit_log_exported
• settings: industries_changed, delivery_configured, sso_configured
• billing: checkout_completed, payment_method_updated

Row-level security

The admin-vs-member scoping is enforced in the database itself via Postgres row-level security, not just in the API layer. Even a buggy route cannot leak another member's events.

Retention and compliance

The 365-day retention window is chosen to balance SOC2 and similar compliance frameworks (which commonly require at least 12 months of audit trail) against keeping the table fast. If your organization requires longer retention, export to CSV monthly and archive the files to your own storage.