BC
Brad CodyAdministrator
Current productPipelines and record experience
Reverse spec drafted

Record Activity

Permanent chronological timeline of external touchpoints, internal work and record changes.

Observed route/admin/leads/:id?tab=activityFuture Spec 14
Current maturityWorking filterable timeline surface with empty live record
Evidence confidenceVerified
Last reviewedAugust 4, 2026
Visual evidenceDeferred during UI updates

Current-state summary

Activity is presented as a permanent record of customer touchpoints, internal work and record changes. The live opportunity contains zero events and exposes summary counters, search, a channel selector and event-type filters for changes, communications, tasks, notes, files and meetings. Earlier evidence confirms dated timeline cards when events exist.

Interface inventory

Anatomy and verified behavior

Verification states separate observed behavior from requirements or assumptions.

ElementCurrent behaviorVerification
Summary countersShows total events, customer touchpoints and record changes.Verified live at zero
SearchSearch activity input narrows timeline content.Control verified; populated filtering not tested
Channel filterAll channels, System, Internal, Email, Phone, SMS and Meeting.Verified live
Type filtersAll activity, Changes, Communications, Tasks, Notes, Files and Meetings with counts.Verified live
TimelinePopulated evidence uses dated chronological cards with event type, author/context and time.Verified from earlier product evidence
Empty stateShows No matching activity and suggests changing type, channel or search.Verified live

User journeys

Current flows

01

Review history

  1. Open Activity
  2. Read counters
  3. Filter type/channel
  4. Search detail
  5. Open related work when supported
Observed result

Surface verified; current record has no events.

02

Record an event

  1. Complete an auditable action
  2. Write canonical event
  3. Classify actor/channel/type
  4. Link source record
  5. Project into Activity
Observed result

Expected cross-module behavior; event emission coverage not audited.

State model

Current and expected states

No events

All counters and filters show zero with a helpful empty result.

Filtered empty

Same No matching activity message is used.

Populated

Earlier evidence shows dated event cards.

Load failure

Not observed for this tab.

Product rules

Non-negotiable boundaries

  • Activity is append-oriented and derived from canonical events.
  • Editing a source record must not silently rewrite prior event meaning.
  • Every event carries Workspace, actor, timestamp, type, visibility and source linkage.
  • Internal events must not leak into Client-visible views.
  • Search and filters do not alter history.
  • The future taxonomy uses External Touchpoint and identifies Client, Designer or Provider where relevant; Customer Touchpoint is retained only as evidence of the current label.
Dependencies
Activity event modelAudit loggingCommunication eventsTasksNotesFilesMeeting/calendar eventsVisibility policy

Known current limitations · 4 mapped

What is missing, broken or unverified

Future Spec 14 owns closure →
  1. The live record has no events, so filtering accuracy was not tested.
  2. No pagination, export or event-detail drawer was observed.
  3. Relationship between Activity and the separate History tab is unresolved.
  4. Raw technical events have appeared elsewhere on the dashboard, suggesting presentation normalization is incomplete.

Future alignment

Required evolution

  • 01Define a canonical event taxonomy shared by Activity, Notifications and reporting.
  • 02Replace Customer Touchpoint with External Touchpoint plus the identified participant type.
  • 03Separate participant-facing Activity from immutable security and audit history.
  • 04Normalize event copy and link each event to its source.
  • 05Support permissions and retention by event visibility class.

Current baseline

Acceptance record

  • Counters, search, channel and type filters are present.
  • Empty state is explicit.
  • Timeline semantics are permanent and chronological.
  • Internal and customer-visible event rules are documented.

Reverse-spec completeness

Documentation coverage

The interface is still changing, so visual evidence and repository tracing remain intentionally incomplete.

Purpose and user outcome

Documented

Roles and access

Documented

Routes and entry points

Documented

Page and component anatomy

Documented

Fields and displayed data

Documented

Primary actions

Documented

Forms and validation

Documented

States and transitions

Documented

Empty, loading and error states

Documented

Responsive behavior

Partial

Accessibility behavior

Partial

Activity and audit events

Partial

Data sources and persistence

Documented

Notifications and automation

Partial

Known defects and limitations

Documented

Reusable component dependencies

Documented

Future-spec conflicts

Partial

Visual and repository evidence

Deferred

Acceptance of current baseline

Documented