Hello, accounts at Cedar
In this invented example, a supplier records accounts@cedar.example as its customer contact. First Leah reads the inbox, then Omar takes over. The supplier's next import uses email as a unique person key and replaces Leah's name with Omar's across years of records.
The mailbox worked exactly as intended: it gave the supplier a stable route to the accounts team. The data model gave it a second job, identifying a human being, without asking whether it was qualified.
A route is a different kind of thing
A contact point describes how someone or something can be reached. In this illustrative model, an email address, telephone number, or postal destination can connect to a person, an organization, or a particular responsibility.
Person identifies an individual human. Organization identifies a group with its own identity and purpose. A route to either is related information, not automatically a substitute identifier.
The person story shows how identity survives role changes. The organization story shows why a company survives a change of representative. A contact relationship gives those changes somewhere sensible to happen.
One route, several readers
A shared inbox can reach several people. One person can have work and personal addresses. A telephone can move between team members. A postal address can serve several organizations. These are ordinary arrangements, not inconvenient exceptions created to annoy database designers.
For Cedar, an illustrative record could connect the mailbox to the organization's accounts function and separately record who handles that function during a period. The supplier can then send a payment query to the appropriate route without claiming the address belongs permanently to Omar.
This is also why a successful message does not prove who read it. Delivery establishes something about reachability. Attribution requires different evidence.
Primary for which purpose?
A field named primaryEmail looks wonderfully settled until the warehouse needs a delivery contact and finance needs an invoice contact. “Primary” needs a context: primary for whom, for what purpose, and during which period?
Cedar might prefer one address for purchasing and another for invoices. The customer story explains why the buyer and the person operating an account can differ. From order to invoice shows why different stages of one transaction may legitimately use different contacts.
Keeping purpose explicit avoids a familiar failure: the newest address wins, and every department discovers the replacement in its own surprising way.
Change the route without rewriting the journey
When Leah hands over to Omar, Cedar can keep the mailbox, update the responsibility, and preserve the earlier transaction history. If the mailbox itself changes, current communication can use the new route while older records retain the details used at the time.
A scheduled workshop creates a similar need. An organizer may change the event contact without changing the event, its purchasing organization, or every attendee. The event story follows that separation.
A useful contact model makes communication easier while keeping identity honest. The message can arrive at the accounts team. Leah can remain Leah, Omar can remain Omar, and the shared inbox can retire from its unexpectedly demanding career as a human being.
