Activity

What It Models

Staff use an activity to retain the context of an interaction. A shared conversation has one record and associations to its participating people and organizations. Classification, outcomes and supporting files are facets of that interaction, with the type supplying the entry settings.

Identity and Attributes

The identifier distinguishes an interaction from its changing subject and participants. A console request retains its creation identifier for recovery, while an import can retain its external reference for matching. Logical attributes cover the interaction, its supporting context, ownership and write safeguards; the structured rows specify their limits and defaults.

Relationships

Activity owns the links to CRM records. Follow-up creation calls Task inside the logging transaction, after which the work has an independent lifecycle. Record Timeline presents an interaction through each surviving association.

Invariants

The structured invariants distinguish ordinary save requirements from retention after record deletion. In particular, a deletion cascade does not reselect a primary or enforce a minimum number of surviving links. Existing planning findings retain the discrepancies involving ownership defaults, locks and console limits.

How It Is Stored and Shared

The activities service owns persistence and exposes the link-transfer function used during a merge. Database cascades provide the deletion exception to normal writes. Entities query views read links for summaries, Platform queries consume registered datasets, and the activity creation path delegates follow-up persistence to Task. History uses shared revision infrastructure with an activity-specific presentation configuration.

Open Design Questions

Authorized management of retained interactions without links still needs its recorded product behavior implemented. Product also needs to settle consistent entry limits and the calendar used for suggested follow-ups.