The Field GuideBusiness Systems
CRM integration: what should be the system of record?
How to assign ownership for customer, deal, billing and operational data before a two-way sync creates two versions of the truth.
By Adi Huric, founder of Most AI LabsAugust 20268 min read
On this page
"Everything syncs both ways" sounds reassuring. It is often a warning.
If a customer's company name changes in the CRM while an integration changes it differently in accounting, which version wins? If both systems can create deals, how are duplicates prevented? If a record is deleted in one, should it disappear everywhere?
Before connecting systems, assign authority field by field and event by event.
A system of record is an ownership decision
The system of record is the accepted authority for a defined piece of information. It does not have to store the only copy, and one application does not need to own everything.
A practical arrangement might be:
- CRM owns prospect identity, sales activity and opportunity stage;
- quoting system owns the accepted scope and commercial version;
- accounting owns invoices, taxes, credits and payment status;
- operations platform owns schedule and delivery status;
- identity provider owns staff access and account status.
IBM's master-data guidance describes master data management as creating a consistent, trusted view of core entities across systems. That is the broader discipline behind the same decision. IBM
Decide at field level
"The CRM owns customers" is not specific enough. Create a register like this:
| Data | Authoritative system | Allowed writers | Conflict rule |
|---|---|---|---|
| Legal business name | Accounting after customer creation | Finance | Accounting wins after verification |
| Preferred contact name | CRM | Sales and customer portal | Most recent verified change |
| Invoice status | Accounting | Finance only | Other systems read only |
| Opportunity stage | CRM | Assigned sales role | CRM workflow validation |
| Delivery date | Operations | Dispatcher | Reject stale updates |
The exact choices depend on the business. The value is making them explicit.
One-way is often safer
If accounting owns payment status, publish that status to the CRM as read-only. There is rarely a reason for a salesperson to overwrite a paid invoice from the CRM.
HubSpot's data-sync documentation supports one-way and two-way synchronization and requires a default conflict-resolution app for two-way field conflicts. The feature does not remove the business decision; it asks you to encode it. HubSpot
Use two-way sync only when both systems legitimately edit the same fact and there is a defensible conflict rule.
Stable identifiers matter more than names
Names, phone numbers and email addresses change. Use a stable internal ID for each customer and store the external IDs assigned by connected systems. Maintain an explicit match table.
Integration operations should be idempotent: repeating the same message must not create a second invoice or customer. Salesforce's integration-pattern guidance calls out idempotent design and allows either Salesforce or an external application to be the data master, depending on the pattern. Salesforce
Design failure before the happy path
For every sync, answer:
- What if the destination is unavailable?
- How many times will the job retry?
- Where does a failed record wait?
- Who is alerted?
- Can the event be replayed safely?
- How is an incorrect update reversed?
- What will the audit log show?
Silent failure is worse than a visible manual queue. A useful integration shows both its last successful run and the records it could not process.
Treat permissions separately from synchronization
Access in one system should not automatically grant access everywhere. Map roles and data sensitivity. A marketing user who can edit a CRM contact may not need invoice detail or support notes.
Microsoft's data-governance guidance recommends beginning with ownership and assigning roles for data quality, access and life-cycle responsibilities. Microsoft Cloud Adoption Framework
The deliverables before development
An integration specification should contain:
- system and data-owner map;
- field dictionary and identifiers;
- triggers and allowed state transitions;
- mapping and validation rules;
- conflict, duplicate and deletion policy;
- retry, alert and recovery behaviour;
- permission and privacy review;
- test cases, including stale and out-of-order updates;
- reconciliation report.
If the team cannot agree on those items, connecting the APIs will not settle the disagreement. It will simply make it travel faster.
Source check
Vendor documentation confirms available sync and integration patterns. Product capabilities and limits can change. The authoritative-system choices shown here are examples and require business, legal and technical review.
Sources
Where this leads
Next step
See where your own visibility stands.
The 7-day audit turns this research into a picture of your business. Yours to keep, whether you hire us or not.
Read next
Build decisions
Build, buy or integrate: when custom software makes sense
A decision framework for choosing custom software, an off-the-shelf product or an integration without turning preference into strategy.
9 min
What things cost
What custom admin platforms cost
A 2026 planning guide to the cost of internal portals and admin software, including discovery, migration, permissions and ownership after launch.
10 min
Build decisions
What a custom CMS is, and when you do not need one
A plain-language guide to content models, editorial workflows and the point at which a custom CMS becomes unnecessary product development.
8 min