Integrating CRM, ERP, ecommerce, customer support, and internal tools does not by itself solve data problems. In fact, it can amplify them when each application retains a different version of a customer, price, or order. The crucial question is not which systems are connected, but which system has authority over each data point and under what conditions.
A source of truth does not have to be a single platform for the entire company. It is a decision made by entity and attribute: the ERP may govern inventory and invoices; ecommerce, the cart and payment status visible to the buyer; the CRM, sales activity; and the support tool, customer service cases. The goal is for every person and process to know where to create, where to edit, where to look up, and how to resolve discrepancies.
The source of truth is not merely where data is stored
A system can contain a copy of a data point without being its source of truth. For example, the CRM may display a customer's balance that comes from the ERP. If a sales representative changes that balance in the CRM, they have changed a replica, not necessarily the value that is valid for finance.
To assign authority, it is useful to separate four responsibilities that are often confused:
- Source of creation: the system that generates the record and its business identifier for the first time.
- Source of update: the system authorized to modify a specific attribute.
- Source of access: the interface through which users or services need to read the value, even if it is a synchronized copy.
- Operational owner: the team that defines rules, quality, permissions, and decisions for exceptions.
This separation prevents simplistic rules such as “the CRM is the customer master.” A customer is not an indivisible block: legal name, delivery address, credit limit, marketing consent, sales owner, and contact preferences may have different owners. Authority must be defined at the attribute level when the process requires it.
You must also distinguish operational truth from historical truth. A product's current price may live in the ERP or in a catalog platform, but the price applied to an already confirmed order must be retained as an order snapshot. Recalculating it from the current price list destroys traceability and can alter reports or claims.
Build the inventory before designing synchronizations
Before selecting connectors, webhooks, or bidirectional integrations, create an inventory of the data that moves across systems. Do not start with screens: start with entities, their attributes, the processes that modify them, and the effects of every change.
A simple authority matrix should include, at a minimum:
- Entity and attribute: for example, product/SKU, product/available inventory, or customer/email.
- Creation system, update system, and access systems.
- The event that triggers the change: creation, payment confirmation, return, inventory adjustment, or case closure.
- Internal identifier and, where applicable, external identifiers.
- Synchronization direction, frequency, and mechanism: event, scheduled process, or on-demand lookup.
- Conflict rule, review owner, and audit trail.
Then classify every field according to its nature. Reference data, such as a product catalog, usually requires editorial control. Transactional data, such as orders and invoices, should be immutable or modifiable through clearly defined events, such as a cancellation or credit note. Derived data, such as a customer's estimated lifetime value, should not overwrite operational data: it needs a formula, source, and calculation date.
Questions that force a useful decision
- Which team is accountable if the data is wrong and causes an incident?
- Which process must approve the change for it to be valid: sales, logistics, tax, or customer service?
- What is the consequence of accepting an old value for a few minutes or hours?
- Can the value be rebuilt from events, or must it be retained as state?
- Which user has the context and permissions to correct it without creating a compliance or financial risk?
If there is no explicit answer, there is no defined authority; there is only a usage habit that will fail as volume increases or another application is added.
Assign authority by data type and business process
There are common patterns, but no universal rules. The right decision depends on the system that executes the process and assumes its consequences.
- Customers: the CRM usually governs opportunities, sales ownership, and sales activity. The ERP may be authoritative for tax data, payment terms, and credit limit. Ecommerce may capture addresses and preferences associated with a purchase, which should be validated before replacing tax data.
- Products: a catalog tool, the ERP, or an internal system may create SKUs and product attributes. Ecommerce often enriches commercial descriptions, images, and channel visibility. Define which fields belong to each domain to prevent an import from deleting editorial content.
- Prices: the current price list must have an authorized source. Promotions may have a separate owner if their engine applies specific rules. The amount of a confirmed order must not be updated when the price list changes.
- Orders: ecommerce may create the order and record purchase intent; the ERP may be authoritative for fulfillment, shipping, invoicing, and returns. Use statuses with precise meanings rather than a single ambiguous field such as “completed.”
- Inventory: the system that records receipts, reservations, adjustments, and shipments should govern sellable inventory. Publishing a copy in ecommerce is common, but allowing ecommerce to adjust inventory without a controlled rule creates overselling and manual reconciliations.
- Consents: the authority must be the system that records the necessary evidence: channel, purpose, date, source, and withdrawal. Copying a simple Boolean value without context reduces the ability to demonstrate what happened.
- Customer service cases: the support tool may govern case history, while an approved return or refund must trigger a process in the appropriate financial or operational system.
In a hypothetical scenario, ecommerce creates the order and emits a payment-confirmed event. The ERP creates the operational order and updates its logistics statuses. The CRM receives a purchase summary for segmentation, but cannot edit the order. Customer service looks up both systems and opens a return request; the ERP confirms the movement and returns the outcome. This matrix reduces the temptation to let every system write to every other system.
Choose an integration pattern that limits conflicts
One-way synchronization is the default option when there is a clear authority: the master system publishes and consumers receive. It is easier to troubleshoot, protects the source, and minimizes update loops.
Bidirectional synchronization is only reasonable when three conditions are met: each system owns different attributes, editing rules are explicit, and conflict-resolution and traceability mechanisms exist. It is not a solution for “keeping everything the same”; that promise usually conceals unresolved decisions.
- Events: appropriate for significant changes such as an order created, payment confirmed, inventory adjusted, or invoice issued. They must include an identifier, event type, date, version, and source.
- Scheduled processes: useful for reconciling missed changes, historical loads, or information that does not require immediacy.
- On-demand lookup: appropriate when the consumer needs the current value and latency is acceptable. It avoids storing copies, but introduces availability and performance dependencies.
- Read replica: necessary for analytics, search, or interface speed. It must be treated as a projection, not as a place for editing.
Design consumers so that events are idempotent: processing the same message twice must not duplicate an order or apply two adjustments. Retain an event key or a version per entity. If an old update arrives, the consumer must detect it rather than silently replacing a newer value.
Define conflicts, identifiers, and history before they happen
A “last update wins” rule may seem objective, but it is unsafe if clocks are not aligned, a system retries messages, or a bulk import has a misleading date. Use it only for low-risk attributes and when the timestamp genuinely represents the business moment.
For critical data, prefer domain priorities and valid state transitions. For example, a paid order should not return to “pending” because a delayed synchronization sent an earlier status. A return may require human review if the support request contradicts the ERP's logistics status.
Every shared entity needs an identification strategy:
- A stable identifier in the source system and external references stored without reuse.
- Matching rules for migrations and manual creation, especially for customers and contacts.
- Duplicate protection: email can help, but it does not always uniquely identify a person or company.
- A change history with the previous value, new value, source, actor or process, and time of the change.
Avoid replacing records when importing data. An update operation must know which version it modifies and which fields it is allowed to touch. When uncertainty is high, route the case to a review queue rather than automatically merging two customers or overwriting an address.
Warning signs and a checklist for approving an integration
There are clear symptoms of an architecture without a source of truth: teams correct the same data in several tools, reports contain incompatible totals, integrations “synchronize everything,” fields have no source description, or incidents are resolved with exports and spreadsheets. It is also a warning sign when no one can explain why a value changed or what will happen if it is edited.
Before approving a new integration, validate this checklist:
- Does every transferred attribute have a documented source of creation, update, and access?
- Is it defined which system can write and which systems can only read?
- Is there a stable identifier and a rule for duplicate creation?
- Does the synchronization direction respond to a specific need?
- Do events include version, source, and the ability to retry safely?
- Are statuses and invalid transitions defined?
- Is there a conflict rule and an owner for exceptions?
- Is enough history retained to investigate changes and reconcile failures?
- Have delays, duplicates, temporary outages, and out-of-order changes been tested?
The best integration is not the one that replicates the most data, but the one that preserves process authority. Start with a small matrix covering the entities that cause the most friction, turn it into a shared operational decision, and use it as a requirement for every new system. This way, integrations stop being opaque pipelines and become a controlled part of the business architecture.