CRM and ERP Data Synchronization: Which System Owns Each Field?

Start CRM–ERP integration planning by assigning authority to each field or business fact, rather than naming one system as master of everything. Agree where records are created, where corrections are allowed, which value takes precedence and who resolves exceptions. Then check whether the selected APIs support those rules.

Start with field-level ownership—not one master system

Use CRM ownership of contact details and ERP ownership of order-processing facts as starting assumptions, not universal rules. Follow your actual workflow: who collects the information, who checks it and who is accountable when it is wrong?

Separate three decisions: the authoritative system, the permitted editing locations and the person responsible for exceptions. Do not interpret an API’s ability to accept an update as permission for that system to determine the business value.

Build a practical data responsibility table

Illustrative example: the following fictional distributor creates contacts in CRM and opens ERP customer accounts after internal approval. This is a planning example, not a VIZUAL customer case or a vendor default. Replace the roles and rules with your own.

Entity or field	Creation trigger	Authority	Permitted editors	Sync direction	Conflict rule	Exception owner
CRM contact record	Sales records a new contact	CRM	Sales in CRM	Selected details to ERP after approval	Review possible matches before creating	Sales operations
ERP customer account	Customer approval completed	ERP	Customer administration in ERP	Account reference to CRM	Check existing mapping before creation	Customer administration
Contact email and phone	Contact creation or verified correction	CRM	Sales in CRM; operations may request corrections	CRM to ERP	CRM value takes precedence; review receiving-side proposals	Sales operations
ERP customer reference	ERP account creation	ERP	ERP creation process; controlled corrections	ERP to CRM	Do not replace from CRM	Customer administration
Order-processing facts	ERP order creation and processing	ERP	Order operations in ERP	ERP to CRM	Use verified field mappings; flag unknown values	Order operations

Keep contacts, organizations and customer accounts distinct in the design. Do not assume one contact equals one customer account. Document the intended relationships, including how several contacts should relate to an organization or account.

Add a correction route and review deadline for each exception owner. A department name alone is not a complete operating procedure: identify who receives the issue and who can approve its resolution.

Choose one-way synchronization before allowing shared editing

Prefer one-way synchronization for each field unless shared editing has a clear business purpose. In the illustrative table, contact details move from CRM to ERP, while customer references and order facts move back. Describe this as different fields moving in opposite directions—not unrestricted two-way editing.

Provide a correction route for receiving-side users. An operations employee who notices an incorrect phone number should be able to request a correction in CRM, rather than silently overwriting the ERP copy.

If both systems must edit the same field, specify:

• Which business rule resolves competing values.
• How the integration checks whether a record changed since it was read.
• How it prevents a synchronized change from bouncing between systems.
• Who reviews conflicts that cannot be resolved automatically.

Treat these as integration requirements to verify, not assumed connector features.

Separate conflicting edits from duplicate records

Illustrative conflict: sales corrects a contact’s email in CRM while operations changes the corresponding ERP email before synchronization completes. Under the example policy, keep CRM authoritative and send the ERP-side proposal to sales for review. Preserve both proposed values in the exception record; do not silently discard the correction request.

Business Central’s documented customer update requires If-Match; an update with a nonmatching ETag does not update the customer. See Microsoft’s Update customers documentation. Use that version check to detect a stale update, then apply your business resolution rule. Do not treat rejection as a decision about which email is correct.

Handle duplicate records separately from competing edits to a mapped record. HubSpot documents Record IDs as unique within an object type, not across all object types. Its Properties guide also documents custom properties that enforce unique values. See the HubSpot Properties API guide.

Maintain a mapping containing the system or account, object type and record ID. Keep that mapping when an email changes. Send ambiguous matches for review rather than assuming different IDs prove different people, or matching names prove the same organization.

Check whether the selected APIs support the agreed rules

The product examples here are based on supplied research excerpts accessed on 11 September 2026, not independently downloaded full documentation. No configured connector or tenant was verified. HubSpot and Microsoft Dynamics 365 Business Central are documentation examples, not product recommendations.

HubSpot’s documented individual contact updates accept Record ID or email. Its batch upserts support email or a custom unique identifier, but partial upserts are not supported when email is the identifier. See the HubSpot Contacts API guide. Check the chosen update method before assuming that an email-based upsert can implement selective field synchronization.

Business Central’s salesOrder resource lists Draft, In Review and Open for status, with fullyShipped exposed separately. See Microsoft’s salesOrder resource documentation. Do not treat that status field alone as a complete delivery or invoicing lifecycle. Verify supporting fields and resources before assigning customer-facing labels such as “Delivered.”

Before approving the design, check current documentation and the selected setup for:

• API version, app type, permissions and field writability.
• Object relationships, identifier rules and customizations.
• Update semantics, including omitted fields and version checks.
• Available change notifications, subscription requirements and applicable limits.
• Deletion and merge behavior, including affected record mappings.

Define freshness and recovery—not an instant-sync promise

Agree acceptable data age separately for contact details and operational order information. Choose those targets from workflow needs rather than a universal threshold. Where useful, show when information was last refreshed and flag records awaiting recovery or review.

The cited HubSpot Webhooks guide documents potentially repeated or out-of-order notifications and says eventId is not guaranteed unique. Its subscription-management functionality is scoped to legacy public apps. See the HubSpot Webhooks API guide. Check corresponding documentation for other app types rather than extending this scope.

Business Central’s webhook documentation describes a default 30-second notification delay and subscription expiry after three days unless renewed. See Microsoft’s Working with webhooks documentation. Do not turn these settings into an end-to-end synchronization promise.

Require repeat-safe processing, subscription renewal where applicable and a recovery procedure for interrupted delivery. Avoid “last notification received wins” as the conflict rule. Define how to reconcile current records after an interruption and who monitors unresolved exceptions.

Sign off the rules with acceptance tests

Turn the responsibility table into testable expectations before enabling broad write access. Include these tests:

1. Create an approved customer and replay the request; expect one mapped customer account.
2. Change an authoritative contact field; verify the intended receiving field.
3. Attempt a receiving-side correction; verify the agreed approval route.
4. Submit competing edits; verify the business conflict rule and review record.
5. Replay a notification; verify that it does not repeat the business action.
6. Deliver an older notification after a newer one; check the resulting value.
7. Encounter a possible duplicate; verify review rather than uncontrolled creation or merging.
8. Interrupt delivery; verify stale-data visibility, recovery and reconciliation.
9. Check a customer-facing order label against every field needed to justify it.

For every test, record the expected result, responsible reviewer and recovery action. Confirm deletion and merge handling separately before enabling those operations. Start with a limited set of fields and expand only after the agreed tests pass.

If you are preparing a CRM–ERP integration, use the completed responsibility table as a starting point for discussing your workflows and integration requirements with VIZUAL.