Master data management: a person is not a contact row

A contact row is a representation created for one workflow. A person can be a lead in CRM, a payer on an invoice, an attendee on a booking, a participant in a channel, a requester in support, and a stakeholder in a project. Treating those rows as the person creates a system that is easy to start and hard to trust.

MINION’s party spine grew out of that mismatch. It is not a glamorous module. It is a shared identity boundary that lets operational systems refer to the same party without pretending that every source has the same quality or authority.

The attractive shortcut

The shortcut is to match records directly. A CRM contact has a phone number; a messaging account has a phone number; an invoice may carry a document or phone field. Join them and the customer journey appears.

That works until it does not:

• a household shares one phone;
• a channel formats an identifier differently;
• a placeholder document value is imported from a billing system;
• one person uses different identities across channels;
• two organizations contain similar records that must never cross;
• a curated field is overwritten by a lower-quality sync.

The dangerous failure is not always a visible error. It is a plausible but incorrect relationship.

The party spine changes the question

Instead of asking “does this CRM row equal this invoice row?”, the system asks:

1. Which party does each record reference?
2. Which identity or alias supports that reference?
3. What source and organization established it?
4. Is the match deterministic, reviewed, unresolved, or rejected?

The party becomes the stable anchor. CRM contacts, finance records, bookings, channel identities, projects, support issues, and agents can keep their domain-specific fields while sharing that anchor.

This is not a demand for one giant person table. It is a demand that relationships be explicit and governed.

Identity quality is operational logic

Identity work is sometimes treated as cleanup after “real” features ship. In practice, it changes what those features mean.

Revenue attribution depends on linking a payer to the right party. A booking checkout needs to know whether a walk-in is a known customer without blocking the sale. A project assignment may refer to a workforce agent rather than a human contact. A CRM merge must preserve the better document or date-of-birth evidence and must not silently collapse two people.

When the party spine became authoritative for shared identity fields, downstream modules could stop inventing their own matching rules. That reduces duplicated logic and makes exceptions visible in one place.

Organization scope is part of identity

Identity is never only a set of field values. In a multi-organization system, scope is part of the claim.

A channel identity observed by one organization is not automatically permission to expose a party in another. A caller-provided organization identifier is not sufficient authority to query or mutate a party. The trusted organization context must come from the authenticated principal and be enforced in the database transaction.

This is why party reconciliation and row-level security belong in the same story. Correct matching without correct scope is still a data leak.

Merge is a decision, not a side effect

A good merge surface must show more than “duplicate detected.” It should make the evidence and consequences inspectable:

• which aliases connect the records;
• which fields conflict;
• which source is more authoritative for each field;
• which relationships will move;
• what remains unresolved;
• how the decision is audited.

MINION’s later CRM work moved in this direction with field-level conflict handling and identity validation. The important design principle is broader: automation can propose a merge, but it should not erase uncertainty to make the interface look clean.

What the party spine enables

Once a shared party boundary exists, the platform can build higher-order views without reconstructing identity each time:

• a customer timeline that includes conversations, invoices, bookings, and support;
• revenue and lifecycle analysis anchored to the same party;
• project and work assignments with explicit stakeholder roles;
• channel identity reconciliation that preserves source provenance;
• governed agent tools that refer to a party rather than accepting arbitrary cross-module identifiers.

These views become useful when the system can explain why each relationship should be believed.

Keep identity scoped and reversible

I would preserve the party as a shared spine, per-organization scope, explicit aliases, protection for curated fields, and the refusal to treat a convenient phone match as universal truth.

Make identity confidence inspectable

I would make identity confidence a first-class, inspectable object. The system should distinguish deterministic identifiers, source-backed aliases, human-reviewed merges, and unresolved suggestions in both API responses and UI. It should also provide a reversible relationship history so that repairing a mistaken merge does not require archaeology.

The quiet work of an ERP is not storing rows. It is maintaining the meaning of relationships as data moves. A person is larger than every contact row that tries to represent them.