Guide · Foundational
Why the Same Customer, Project or Order Has Five Different Names
An organisation can know that five records refer to one request while none of its systems can prove the connection.
Define the object, preserve local identities and govern the mapping between them.
Five names, several meanings
Consider an illustrative customer request called “Smith Lift” in a spreadsheet. CRM records Opportunity 1842. Engineering opens Project S1042. Purchasing uses Job 6621. An email thread refers to the site name. A colleague remembers that these records belong together and manually supplies the right reference whenever work crosses a boundary.
These identifiers are not necessarily mistakes. Each system serves a different purpose. An opportunity, a project and a purchasing job may be distinct business objects with relationships, rather than five aliases of one object. The first task is to establish what each record represents. Replacing every identifier with one number can erase useful distinctions.
Identity is a relationship, not a string match
A business object is a meaningful entity in the work: customer, request, order, asset or project. The label used in one tool is only part of its representation. Two records with similar names may concern different sites or revisions. Two records with different names may represent successive stages of one request.
Ask what evidence establishes the relationship. It might be an explicit reference, an approved mapping or a combination of controlled fields. A name similarity score can propose a candidate match, but it should not silently become authority. Include cases where a request becomes several jobs, where projects merge and where a customer changes its trading name.
Why people become the crosswalk
People often supply the missing links because they have lived through the object’s history. They know that an old project reference survived in purchasing or that the spreadsheet uses the customer’s informal name. This knowledge makes work possible but can be difficult to share, audit or update reliably.
Observe how the mapping is used in real handoffs. Which references get copied? Which mismatches cause delays? Who notices when an identifier has become obsolete? Treat the person’s knowledge as evidence to investigate, not as a nuisance to remove. Some mappings can become explicit rules; others require a contextual decision.
A governed canonical identity
A canonical identifier can give the organisation a stable way to refer to an entity, while preserving local system IDs and their meanings. A mapping should say which entity each ID represents, its source, its valid period and how the relationship was established. It should not imply that every field belongs to one globally authoritative system.
Define ownership and correction procedures. Who can merge records? What happens when one project splits into several orders? Can a correction be traced to the person and evidence that justified it? Where uncertainty remains, represent the candidate relationship as uncertain instead of forcing a premature match. The objective is dependable reference, not cosmetic consistency.
Automation makes identity consequential
A human may catch an implausible reference before acting. An automated workflow may propagate it instantly to several destinations. An agent retrieving context can combine facts from different entities if its tools do not preserve identity and scope. A plausible response can then conceal an incorrect join.
Establish identity before granting cross-system actions. Give integrations explicit contracts and agents scoped tools that retain provenance. Verify that the requested action affected the intended object and that the approved values reached the destination. A Company MCP can provide a governed interface, but the protocol itself cannot resolve business identity. The organisation still has to define the objects, relationships and evidence behind the tools it exposes.
Questions worth asking
- Are these records aliases of one object or different objects in a lifecycle?
- What evidence establishes the relationship?
- Who handles merges, splits and corrections?
Foundational explanation and illustrative examples. This article does not report findings from client engagements or establish a pattern in your organisation.