Interactions at a glance
What it is
Master data describes what things are. Interactions describe what happened to them — a branch visit, a support call, a clinical encounter, a claim notification.
Much of the value of a 360 view comes from having both.
Interaction versus relationship
| 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.
The pieces
| Piece | Is |
|---|---|
| Interaction type | A kind of event, optionally binding a participant-role list |
| Interaction | An instance: a status, when it occurred, a subject |
| Participant | Another entity, in a role from the bound list |
Multiple participants
A meeting has attendees; a transfer has a sender and a recipient; a consultation has a patient and a clinician.
Roles are validated against the type's bound list, so an interaction cannot record a participant in a role its type does not define. That is what keeps a timeline queryable rather than accumulating free-text role labels.
Record when it occurred
Not when it was loaded. A timeline ordered by load time is not a timeline.
Merging
Interactions move to the survivor and the timeline becomes whole. Where both records participated in the same interaction in the same role, the duplicate participation collapses rather than listing the survivor twice.
Where they held different roles, both rows survive and the survivor appears twice in that event — correctly, because one party genuinely acted in two capacities.
A current limitation
Types carry no per-type attribute schema. If you need richer structure per type, raise it as a gap rather than working around it with free-text conventions.
Next
Last verified against commit 1e1de1ad (2026-08-03)