--- title: "CRM synchronisation needs field ownership and conflict rules — Orvun Labs" description: "A CRM sync should preserve meaning, not merely copy the newest row. Decide which system owns each field and which changes users are allowed to make locally. Record matching rules and deletio" canonical: "https://orvunlabs.com/en/journal/crm-sync-data-ownership" language: "en" last_modified: "2026-09-13" --- # CRM synchronisation needs field ownership and conflict rules A CRM sync should preserve meaning, not merely copy the newest row. Decide which system owns each field and which changes users are allowed to make locally. Record matching rules and deletio ![CRM synchronisation needs field ownership and conflict rules](https://orvunlabs.com/images/blog/integrations.svg) - Published: 2026-09-13T09:00:00.000Z - [Connected systems](https://orvunlabs.com/en/journal/topic/integrations.md) ## The decision A CRM sync should preserve meaning, not merely copy the newest row. Decide which system owns each field and which changes users are allowed to make locally. Record matching rules and deletion behaviour before enabling writes in both directions. ## A worked example In an illustrative sales workflow, the CRM owns the account manager while the billing system owns the invoice address. A contact updates their email in a portal while a salesperson edits their phone. A whole-record overwrite could lose one valid change; field-level ownership and version checks make the decision explicit. ## Alternatives worth weighing One-way synchronisation is simpler when ownership is clear. Two-way synchronisation helps genuine shared editing but requires conflict handling. A review queue may be safer than automatic last-write-wins for fields whose meaning cannot be judged from timestamps alone. ## Where the plan breaks Do not use email as a permanent identity without considering changes and shared addresses. Distinguish an archived contact from one that must be deleted under the applicable policy. Avoid an endless loop where each system interprets the other's copy as a new update. ## Specify a conflict with two legitimate edits Extend the illustrative contact change with field versions and origin. The portal changes the email while a salesperson changes the phone. The integration should preserve both changes when the agreed ownership allows them. If two systems change the same field from the same earlier version, retain both candidates and route the conflict according to an explicit rule. A timestamp alone may not express authority, particularly when devices or imports report different clocks. For a reviewed conflict, show previous value, proposed values, source systems and linked activities. The resolver should understand what will change before approving it. Avoid automatically merging records merely because names look similar. A stable internal identity and an explicit cross-system mapping are more dependable than a changeable email address. Decide who may approve a merge and how activities, attachments and company relationships follow the surviving identity. ## Make correction and deletion observable A synchronisation loop can start when each system treats the other’s copy as a fresh edit. Preserve a change identifier and origin, and compare meaningful field values before emitting another update. Test whitespace normalisation and equivalent phone formatting so harmless representation changes do not produce endless traffic. Version the mapping rules; a rollout that reformats every record can otherwise resemble a mass business update. Handle archive, merge and erasure as distinct events under the owner’s applicable policy. Plan how a removed record stays removed when an old import or restored backup appears. A private deletion register or another approved recovery mechanism may be needed; it should not expose unnecessary personal information. Before enabling bulk writes, rehearse a duplicate merge, a permission change and recovery after interrupted processing. The CRM administrator owns meaning and access; the integration team owns reliable transfer and evidence of unresolved work. ## Before you commission the work Who can resolve conflicting changes? Can operators see both values and their origin? What happens to linked activities when a record merges? Bring duplicate and deletion examples to the integration discussion before running a bulk sync. ## System integration Make your tools work together. - [Discuss this service](https://orvunlabs.com/en/services/system-integration.md) ## Related reading - [Why webhooks need idempotency, retries and reconciliation](https://orvunlabs.com/en/journal/webhooks-idempotency-retries.md) - [Connecting a legacy system through a new API](https://orvunlabs.com/en/journal/connecting-legacy-systems-apis.md) ## Let's make something useful. A first product, a difficult workflow or software that needs a fresh start. Tell us where you are. - [Tell us about your project](https://orvunlabs.com/en/contact) ## Structured data ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://orvunlabs.com/#organization", "name": "Orvun Labs", "url": "https://orvunlabs.com", "logo": "https://orvunlabs.com/orvunlabs-icon-512.png", "description": "Custom software, SaaS products and AI-powered tools — designed around your business.", "knowsAbout": [ "Custom software", "SaaS product development", "AI integration" ] }, { "@type": "WebSite", "@id": "https://orvunlabs.com/#website", "name": "Orvun Labs", "url": "https://orvunlabs.com", "inLanguage": [ "en", "es", "de", "fr", "pt", "ja", "hi", "ar", "id", "tr", "pl" ], "publisher": { "@id": "https://orvunlabs.com/#organization" } }, { "@type": "WebPage", "@id": "https://orvunlabs.com/en/journal/crm-sync-data-ownership#webpage", "url": "https://orvunlabs.com/en/journal/crm-sync-data-ownership", "name": "CRM synchronisation needs field ownership and conflict rules", "description": "A CRM sync should preserve meaning, not merely copy the newest row. Decide which system owns each field and which changes users are allowed to make locally. Record matching rules and deletio", "inLanguage": "en", "isPartOf": { "@id": "https://orvunlabs.com/#website" }, "about": { "@id": "https://orvunlabs.com/#organization" }, "breadcrumb": { "@id": "https://orvunlabs.com/en/journal/crm-sync-data-ownership#breadcrumb" } }, { "@type": "BreadcrumbList", "@id": "https://orvunlabs.com/en/journal/crm-sync-data-ownership#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Orvun Labs", "item": "https://orvunlabs.com/en" }, { "@type": "ListItem", "position": 2, "name": "CRM synchronisation needs field ownership and conflict rules", "item": "https://orvunlabs.com/en/journal/crm-sync-data-ownership" } ] }, { "@type": "BlogPosting", "headline": "CRM synchronisation needs field ownership and conflict rules", "description": "A CRM sync should preserve meaning, not merely copy the newest row. Decide which system owns each field and which changes users are allowed to make locally. Record matching rules and deletio", "datePublished": "2026-09-13T09:00:00.000Z", "dateModified": "2026-09-13T09:45:03Z", "inLanguage": "en", "author": { "@id": "https://orvunlabs.com/#organization" }, "publisher": { "@id": "https://orvunlabs.com/#organization" }, "image": [ "https://orvunlabs.com/images/blog/integrations.svg" ], "mainEntityOfPage": { "@id": "https://orvunlabs.com/en/journal/crm-sync-data-ownership#webpage" } } ] } ```