Tracking interactions
An interaction is something that happened involving one or more entities: a branch visit, a support call, a clinical encounter, a claim notification.
Master data describes what things are. Interactions describe what happened to them — and much of the value of a 360 view comes from having both.
Interactions and interaction types
Recorded interactions across all entities, most recent first.
An interaction type defines a kind of event; interactions are its instances, each carrying a status and the time it occurred.
Multiple participants
An interaction is not limited to one entity. A meeting has several attendees; a transfer has a sender and a recipient; a consultation has a patient and a clinician.
Each participant has a role, drawn from a controlled list bound to the interaction type. Roles are validated against that list, so an interaction cannot record a participant in a role its type does not define.
Merging
When entities merge, their interactions move to the survivor and the timeline becomes whole. Where both records participated in the same interaction, the duplicate participation is collapsed rather than leaving the survivor listed twice in one event.
Unmerging restores the original arrangement.
Interactions versus relationships
Easily confused, and worth separating:
| Represents | Time | |
|---|---|---|
| Relationship | A standing link — employment, ownership | Holds over a period |
| Interaction | A discrete event — a call, a visit | Happens at a point |
"Works for" is a relationship. "Attended an interview" is an interaction.
Advice
- Define types before loading. Retrofitting a type onto existing interactions means reclassifying them.
- Bind participant roles to a controlled list, so a timeline stays queryable rather than accumulating free-text role labels.
- Interactions accumulate faster than entities. Plan volume with that in mind.
Next
Last verified against commit 315eb047 (2026-08-03)