Activity
What It Is
An activity is the customer’s account of an interaction involving a person or organization. A call, email, meeting or note gives staff something they can review before the next conversation. The record can describe something completed, cancelled or still scheduled. Its identity remains distinct from its subject, date and the names of the people involved, so later corrections do not require a new interaction record.
A coordinator creates an activity from a related record, and imports can bring earlier interactions into the same collection. Each activity refers to its type and the contacts or organizations it concerns. This differs from the earlier model in which one interaction belonged to one contact or one organization: a shared meeting can now be recorded once and viewed in several contexts.
What It Is Not
An activity is separate from a task. The activity describes the interaction; a task carries work someone needs to manage. A follow-up can connect those purposes during creation, but completion of the task does not itself create another interaction. Activity history is also different from the record timeline: history explains edits to this entry, while the timeline places it beside other interactions and work.
How It Is Used
Coordinators log interactions, readers consult them, and authorized colleagues correct inaccurate details. Before calling a member, staff can review recent conversations and decide what remains to discuss. A useful entry identifies the records involved and preserves enough context for someone else to understand the interaction. Selecting the appropriate type makes that context easier to enter and interpret.
A lost response can leave staff unsure whether their entry saved. The create and edit recovery behaviors address that uncertainty. Concurrent corrections can still require reconciliation, and locks can prevent an otherwise permitted edit. An activity that loses all related links remains retained but cannot open through the normal record landing.
Its Facets
Related records and primary context. Links identify the people and organizations involved. One primary selection supplies the preferred context, while other linked contacts can represent attendees.
Type and field modes. Classification belongs to the activity concept. Types shape subject, direction, duration, outcome, end-time and attendee controls. A hidden attendee control does not make linked contacts invalid.
Status and outcomes. Status places the interaction in past or upcoming work. Outcomes describe its result using the selected type’s own choices; the outcome catalog can change without discarding earlier selections.
Ownership and attribution. An owner supports personal views and filtering. Creation and modification attribution explain who wrote the record and remain separate from ownership. Initial user creation still defaults an empty owner back to its caller, an unresolved difference from the No Owner choice.
Notes and files. Formatted text preserves discussion detail after cleaning. Managed attachments keep supporting documents associated with the entry, although the console currently lacks upload entry.
Defaults and follow-up. Type settings suggest initial status, duration and follow-up timing. A follow-up requested during logging becomes a separate task with its own lifecycle.
Baseline identity, presentation and retirement. Built-in codes distinguish standard categories despite renamed labels. Icons, colours and list position help staff recognize types. Deactivation provides a way to stop offering a selection while retaining prior use.
Origin. Source classification and external references help staff distinguish entered, imported and system-created interactions and support later source matching.
How It Relates
Contacts and organizations provide the interaction contexts. Record timelines present those links alongside tasks. Task creation owns follow-up work, Platform owns managed file storage and import orchestration, and the activity’s revision history preserves changes to its own record.
What It Could Become
The product should finish management of retained activities with no links and the recorded deletion-audit requirements. It should also choose consistent duration and follow-up limits across console and service, settle the follow-up calendar, and decide whether console users need upload support. These decisions can extend the activity without turning each setting or attachment into another broad concept.