Activity log

Problem Context

• Events may come from users, admins, service accounts, automation, integrations, or system processes.
• Users inspect the log for troubleshooting, security review, compliance, incident response, permission review, billing disputes, change review, or operational proof.
• Records may have retention windows, role-gated access, redacted fields, delayed ingestion, duplicate delivery, timezone normalization, or export constraints.
• The surface often spans multiple apps, workspaces, objects, groups, locations, devices, and event types.

Selection Rules

• Choose activity log when the task is evidence review, investigation, compliance, security monitoring, or operational troubleshooting.
• Use timeline when users only need a readable summary of important events for one object or process.
• Use feed when users consume a live or personalized stream and reading position matters more than evidence completeness.
• Use notification center when users need personal triage, unread state, badge behavior, and notification preferences.
• Use search history when users manage their own stored query activity and deletion or pause controls are the primary need.
• Use table or data grid when event records need dense column comparison, sortable fields, column selection, or export-ready row structure.
• Include actor, action, object, timestamp, source, result, and event ID before adding visual summaries.
• Show active filters, query, timezone, retention window, permission scope, and result count near the log.
• Provide detail expansion for changed fields, request metadata, IP/location, source app, raw payload, or related records where appropriate.
• Label redacted, delayed, duplicate, corrected, archived, failed-ingestion, unavailable, and out-of-retention states.
• Do not promise deletion, completeness, or legal proof unless the retention and backend record model support that claim.
• Design export and API access as first-class behavior when the log supports investigation beyond the UI.

Required States

• Default log state with event records, result count, visible timezone, retention window, and permission scope.
• Filtered and searched states by actor, action, object, app, date range, result, IP, location, or event ID.
• Expanded event detail state with changed fields, source, event ID, request context, and related object route.
• Export queued, export ready, export failed, and export range mismatch states.
• No results, empty log, loading, delayed ingestion, offline, failed-load, and retry states.
• Redacted, permission-limited, out-of-retention, archived, corrected, duplicate, and deleted-object states.
• Saved query or copied query state when investigation workflows support reuse.
• Responsive state where event identity and critical metadata remain readable without hiding scope.

Interaction Contract

• Each log row identifies one recorded event and keeps actor, action, object, timestamp, and event ID stable across filtering, sorting, expansion, export, and refresh.
• Filters narrow visible records without deleting or mutating log evidence.
• Search and date range controls state the timezone and included endpoints used by the query.
• Opening details reveals additional evidence for the same event and does not summarize multiple events as one record.
• Export uses the same query, range, timezone, fields, and permission scope shown on screen or explains the difference before export.
• Redacted or unavailable fields explain whether data is hidden by permissions, policy, retention, ingestion delay, or source-system loss.
• Records are not removed by notification read state, user-facing dismissal, or personal history deletion unless the backend policy explicitly allows it.
• After refresh, export, expansion, or filter changes, focus remains near the triggering control or updated result summary.

Implementation Checklist

• Define event schema: event ID, timestamp, timezone, actor, actor type, action, object, object type, source app, result, IP, location, request ID, before and after fields, retention class, and export eligibility.
• Separate activity-log records from feeds, notification records, search history, analytics events, and timeline summaries in the data model.
• Build filters for actor, action, object, app, result, event type, date range, IP/location, and event ID according to real investigative tasks.
• Display active query, scope, result count, timezone, retention window, ingestion freshness, and permission limitations near the log.
• Implement details, copy event ID, copy query, saved query, export, retry, and archive routes with explicit status feedback.
• Model redaction, retention cutoff, duplicates, corrected timestamps, delayed ingestion, failed export, deleted objects, and scoped administrator access.
• Test long actor names, service accounts, missing IPs, redacted fields, partial exports, timezone changes, virtualized rows, keyboard expansion, screen-reader row identity, and mobile metadata wrapping.
• Audit telemetry so sensitive log contents are not leaked into unrelated analytics while still recording use of log controls.

Common Generated-UI Mistakes

• Calling a social feed or notification drawer an activity log without event evidence.
• Using vague activity labels that omit actor, action, object, timestamp, or result.
• Hiding retention limits, permission scope, or redaction until after users fail to find records.
• Letting mark-read, dismiss, archive, or personal-history deletion remove administrative evidence.
• Showing local browser time in the UI while export uses UTC without disclosure.
• Exporting a different field set, date range, or filter query than the visible results.
• Treating streamed duplicate events as separate confirmed actions without duplicate indicators.
• Using activity log as a timeline summary when users need searchable, exportable records.

Critique Questions

• What question does this log answer: who, what, when, where, before and after, or whether the record exists at all?
• Which event fields are required for investigation, and which are unavailable, redacted, delayed, or out of retention?
• Can users tell the active query, date range, timezone, result count, permission scope, and retention window?
• Does export exactly match the on-screen query and field set, and does the UI say when it does not?
• What happens to log records when notifications are read, objects are deleted, users leave, or personal history is cleared?
• Would timeline, feed, notification center, search history, table, or data grid better fit this surface?