Record Timeline

What It Models

Staff read a timeline to understand one relationship’s interactions and work. Upcoming and History present a computed stream assembled from activity associations and task references. The view has no independent persistence or ownership of those records.

Identity and Attributes

The record address establishes context. A request specifies its section and filters, while the cursor retains each source’s position. Item attributes carry time, overdue standing and permission-based editability. A separate summary describes the full record context rather than the loaded page.

Relationships

The view combines Activity and Task within CRM and is hosted by the contact and organization screens. Selecting work opens the task drawer. Removing an association changes the view without removing its underlying interaction or work.

Invariants

The structured rows define read authorization, task visibility and continuation behavior. Continuation assumes unchanged inputs; it provides no snapshot spanning page requests. Permission-based editability can still lead to a lock refusal on save.

How It Is Stored and Shared

The activities service implements the timeline and summary reads. Activity links supply indexed time, status and type copies, while task rows supply work context. Console record screens consume these reads and keep no alternative timeline store.

Open Design Questions

Editing signals still need alignment with locks. Large-record owner aggregation may need further evidence before introducing another stored value. Retained interactions without associations have no timeline context.