CASE STUDY 02 · SALESFORCE · ERP INTEGRATION · CUSTOMER IDENTITY
When One Customer ID Isn't Enough
Resolving complex customer relationships across Salesforce and ERP — where technical integration must accommodate business reality.
The Challenge
Introducing Infor Enterprise Quoting (EQ) into Salesforce appeared to create a straightforward integration requirement. Its managed package included an Account External ID field linking a Salesforce Account to an Infor CSI ERP Customer so that customer-specific pricing could be retrieved.
But the two systems represented customers differently.
Salespeople worked with individual clinics and locations where purchasing decisions were influenced. The ERP was structured around billing Customers and Ship-to locations. A clinic might purchase directly, through a headquarters or buying organisation, or via a distributor.
The ERP also contained genuine duplicate records, created through human error and integrations that had been designed without sufficient consideration of the wider enterprise landscape.
The fundamental question was not simply how to connect two systems, but which ERP entity a Salesforce Account actually represented.
The Diagnosis
I recognised that the managed package's External ID requirement was too narrow to represent the full relationship between Salesforce and ERP.
One billing Customer could have multiple Ship-to locations, each represented by a different Salesforce Account. Storing only the ERP Customer number would lose that distinction.
The problem was compounded by ambiguity in the underlying customer data. Some records were duplicates that needed correcting; others represented legitimate differences between physical locations, billing relationships and purchasing arrangements.
It was therefore essential to distinguish between customer identity, the appropriate ERP location and the customer relationship required for a particular transaction.
The Approach
Establishing the initial customer relationships
Salesforce was already live when Enterprise Quoting was introduced, so I initially populated Account External IDs retrospectively.
I used address matching in Excel to identify candidate ERP records, then examined them to determine the appropriate Customer and Ship-to relationships.
I requested a modification to the managed package so that Salesforce could retain a combined identifier:
Customer Number + "_" + Ship-to Number
This preserved the specific ERP location represented by each Salesforce Account. When Enterprise Quoting required pricing, the Ship-to component was removed and only the Customer number was passed to Infor CSI.
The wider CRM/ERP architecture was therefore not constrained by the narrower requirements of one application.
Turning matching into an operational capability
A later project introduced Demo Requests from Salesforce into ERP.
Some prospective customers had no suitable ERP Customer record, and creating one could take time because of processes such as credit checks. The business nevertheless needed to supply demonstration products promptly.
I designed an address-matching capability that used middleware to convert Salesforce and ERP addresses into geographical coordinates, calculate distances and identify plausible ERP matches within a defined threshold.
At submission, the salesperson could review candidate records showing the Customer and Ship-to identifiers, company name and address.
They could select an appropriate existing entity or request a new Ship-to against a temporary Customer associated with the salesperson.
The technology narrowed the possibilities; the person with the business knowledge made the final decision.
Recognising the importance of business context
The ERP entity selected for one transaction was not necessarily the permanent identity of the Salesforce Account.
Where an Account already had an External ID, selecting a different ERP entity for a Demo Request did not overwrite that existing relationship.
This distinction became even more important as Salesforce expanded into Service Cloud.
Repairs, returns and refunds could legitimately require different ERP customer relationships. For example, a clinic might purchase through NHS Supply Chain, meaning the appropriate entity for a financial transaction could differ from the physical clinic relevant to a service process.
The architectural question was therefore not always which ERP Customer belonged to an Account, but which relationship was appropriate for the transaction being performed.
Challenging unnecessary duplication
As further Salesforce/ERP use cases emerged, I advocated extending the existing customer-matching and selection approach.
An alternative Service Cloud design introduced another field on ERP Ship-to records to identify a single 'direct customer'.
I challenged this because it duplicated a relationship the existing architecture was already intended to resolve, introducing additional questions about data ownership, synchronisation and lifecycle management.
More fundamentally, a single predefined customer relationship could not reliably accommodate every business process.
I repeatedly recommended extending contextual matching and selection into Service processes. The implemented design instead relied on a manually maintained 'direct customer' value in ERP.
The Results
Preserved customer relationships
Customer and Ship-to identity retained without compromising the quoting package's pricing requirement.
Operational matching
Plausible ERP matches presented to salespeople at the point of transaction.
Contextual control
Transaction-specific selections did not overwrite an existing persistent Account relationship.
The customer-matching approach was implemented as part of the Demo Request process, enabling salespeople to identify an appropriate ERP entity without relying solely on manual searching or an automatically imposed relationship.
The solution preserved the distinction between persistent Salesforce Account identity and the ERP entity required for an individual transaction.
The subsequent Service Cloud implementation did not adopt the contextual approach I recommended and has not achieved full process adoption, with some users continuing to work through previous methods.
In my assessment, one contributing factor was the reliance on a predefined customer relationship rather than consistently supporting the contextual decisions required by different service processes.
A subsequent architectural review, approximately four years later, revisited the approach to managing customer relationships across Salesforce and ERP. Senior IT leadership and technical specialists independently reaffirmed the underlying architectural direction, reinforcing the importance of distinguishing persistent customer identity from transaction-specific relationships.
Architectural Judgement & Lessons
Not every duplicate represents bad data.
Some records are genuine duplicates that should be eliminated. Others represent legitimate differences in customer relationships, locations and purchasing arrangements.
The architecture must distinguish between them rather than assuming every apparent duplication is an error.
Persistent identity and transaction-specific relationships are different concerns.
A Salesforce Account may have an established relationship with an ERP Customer, but that does not mean the same ERP entity is appropriate for every quote, repair, return or refund.
The correct relationship may depend on the business process.
Temporary relationships need an explicit lifecycle.
There was also a weakness in my original design.
Where an Account had no External ID, selecting a temporary ERP Customer for a Demo Request could write that identifier back to the Account without an explicit mechanism to mark it as provisional or replace it later.
I would now distinguish more clearly between persistent customer identity, contextual transaction routing and temporary mappings, with an explicit process for resolving provisional relationships.
I would also improve candidate matching by incorporating additional business rules rather than relying on geographical proximity alone.
Good architecture doesn't eliminate ambiguity by pretending it doesn't exist. It identifies where technology can make a reliable decision and where human judgement remains essential.