Every integration you build silently encodes a belief: this system is the truth, the other one is the copy. The moment two systems disagree about a customer's email, an order's status, or an employee's start date, the integration has to pick a winner. Which system wins is a decision worth making once, consciously, before you spend three years arbitrating it ticket by ticket.
Picking your system of record (SoR) for each domain — customers, products, finance, employees — is the most important integration decision you'll make, and most teams make it by accident. This is a working method for making it on purpose.
What “system of record” actually means
For any data entity in your business, the system of record is the one place where:
- The authoritative version of that data lives.
- Updates originate (or at least get blessed).
- Other systems sync from, never to.
That last clause is the one most teams violate. The CRM is meant to be the customer SoR — but the support team edits emails in the helpdesk, and finance edits billing addresses in the ERP. Now you have three systems of record for the same entity. Which is to say, none.
You need one per domain, not one in total
A common confusion is the idea that there should be one system of record for everything. There shouldn't. Different domains have different natural homes:
- Customers— usually CRM (HubSpot, Salesforce, Pipedrive). Sometimes the product database, if you're a SaaS company and product is where the customer relationship actually lives.
- Products / SKUs — usually an ERP, PIM, or the ecommerce platform. The one closest to where products are actually defined.
- Orders / invoices — usually the ERP or dedicated billing system. Almost never the CRM.
- Employees — usually the HRIS. The IT identity system is downstream of HR, not the other way around.
- Contracts — usually a CLM or document management system. Treating the CRM as the contract SoR is the path to a legal incident.
The rule of thumb: pick the system where the data is createdand updated most often by its native users. That's almost always the right SoR.
The decision criteria nobody writes down
Four questions, asked honestly, will resolve most SoR debates:
- Where is the data created? The system where new records appear first has a natural claim to authority.
- Where is it updated most? If sales updates the customer in the CRM and finance updates the same customer in the ERP, you have a problem. Pick whichever team genuinely owns the ongoing relationship with that data.
- Who has to trust it most? If finance reporting depends on a number being right, finance has a strong claim on the SoR for that number. Trust follows responsibility.
- What's the cost of being wrong? A wrong billing address is worse than a wrong job title. The system handling the higher-stakes data should be the SoR for it.
When two systems both have strong claims (CRM and ERP both touch customers, for example), split by attribute. Email and phone belong to the CRM; billing address and tax ID belong to the ERP. Each attribute has its own SoR.
The two patterns for staying consistent
Pattern A: SoR + downstream copies (most common)
Updates happen in the SoR. Changes flow outward via webhooks or scheduled sync to every downstream system that needs the data. Downstream systems are read-only for those attributes — or any edits made there are explicitly synced back as an event, not silently held.
This is the right pattern for most mid-sized businesses. It's simple, auditable, and survives staff turnover. The hard part is the discipline: locking down the downstream UIs so people can't edit fields they shouldn't.
Pattern B: master data hub (when you outgrow Pattern A)
A dedicated master data management (MDM) layer sits in front of every system. All edits go through the hub; the hub propagates to operational systems. Larger organisations with five-plus operational systems often need this; smaller ones almost never do.
The honest signal that you need an MDM: you've got more than three systems that genuinely co-author the same data, and the reconciliation work has become its own job.
The patterns that don't work
- Bidirectional sync without a winner. The most common SoR failure. Two systems update each other in a loop; when they disagree, one randomly wins. Eventually they diverge and the integration has to be manually reconciled.
- The “last writer wins” convention.Looks elegant; breaks the first time someone's mass-update script runs at 3am. Conflicts should require a decision, not be resolved by timestamp.
- The spreadsheet of truth.When the answer to “where is this data really right?” is a shared spreadsheet maintained by one analyst, you have an SoR — it just happens to be the worst possible one.
How to migrate to a proper SoR
Most businesses don't pick their SoR on day one — they inherit a mess. Getting from mess to clean architecture is a staged exercise:
- Pick the SoR per domain.Write it down. Get sign-off from the heads of the affected functions. This is the conversation that's most often skipped and most often regretted.
- Audit current edit paths. For each domain, where is the data being edited today? Which of those paths should remain after the migration?
- Lock the non-SoR edit paths.Either remove the UI permission, change the workflow, or make the field read-only downstream. This is where the political work lives — someone will lose access to a field they've always edited.
- Build the sync. Once edit paths are locked, the integration becomes simple: SoR → downstream, with no return path.
- Reconcile historical data.Pick the most trustworthy current value for each conflicted record and write it back through the SoR. Don't do this in bulk without a dry run.
The CRM-as-SoR trap
A specific warning: don't default to the CRM as the SoR for everything customer-shaped. The CRM is excellent for customer identity, deal stage, and relationship metadata. It's a poor SoR for product entitlements, billing data, support history, and anything finance has to sign off on. Trying to make the CRM the SoR for all of these creates a customer record that's simultaneously the messiest object in your stack and the most business-critical.
Better: CRM as SoR for identity and the sales relationship. Billing system as SoR for invoices and balances. Product database as SoR for entitlements. Helpdesk as SoR for support history. They sync customer IDs; they don't sync everything.
The honest bottom line
Picking systems of record is a 90% governance exercise and a 10% technical one. The hard part isn't the sync; it's getting heads of functions to agree that their team isn't the authority for a field they've always edited. That conversation, held once and written down, replaces years of ticket-by-ticket arbitration.
If you only act on one thing from this post, write a one-page document that says “these are our systems of record per domain, and these attributes are owned by which.” Get the affected heads to sign it. Pin it on the integrations wiki. Future integration decisions become small and obvious.