Use case · CRM data
CRM sync that knows which system wins each field
Contacts, companies and deals change in several tools at once. We build the sync between them: every field has a written owner, duplicates match on stable keys, unsure merges wait for a person, enrichment uses only sources you approve, and a morning report shows what did not reconcile.
At a glance
- What it takes on
- Map field ownership
- Sync changes both ways
- Find and merge duplicates
- Enrich the blanks
- Connects to
- Your CRM
- Forms and booking tools
- Billing or order system
- Approved enrichment source
- n8n, Make or custom code
- Supabase or your database
- Typical rollout
- Week 1 → Weeks 5–6See the plan
The problem
Where the work gets stuck today
Most teams already connect their CRM to forms, billing and the helpdesk, one connection at a time, so nobody wrote down which system is right when two disagree. A rep corrects a phone number in the CRM, billing sends the old one back an hour later, and the correction is gone without anyone noticing.
Duplicates follow. A lead uses a work email on a form and a personal one to book a call, and now exists twice; an enrichment tool adds a third spelling of the company. Reports drift, routing fires on the wrong record, and the team goes back to private spreadsheets.
| Symptom | Usual cause | What fixes it |
|---|---|---|
| Edits disappear | Two-way sync with no field owner, so the last write wins | A written owner per field and a rule for every conflict |
| Duplicate contacts | Matching on a name, or on an id only one system has | Match keys in priority order, with near matches sent to review |
| Enrichment overwrites good data | Bought data treated as more reliable than what a person typed | Enrichment fills blanks only, with its source and date stored |
Task catalog
What the system takes on
Task 01
Map field ownership
Every field that moves between systems gets an owner, a list of who else may write it and a conflict rule. The table becomes configuration the sync reads, not a slide.
Task 02
Sync changes both ways
Changes travel as webhook events where a tool supports them, and by scheduled polling where it does not. Each write carries a key from the source record and version, so a repeat never applies twice.
Task 03
Find and merge duplicates
Records match on keys in priority order: a shared id, normalised email, phone, then company domain with name. Exact matches merge by your rules; near matches wait for a person.
Task 04
Enrich the blanks
Empty fields such as industry, size band or region are filled from sources you approve, each value stored with its source and date. Enrichment never overwrites what someone typed.
Task 05
Normalise on the way in
Phone numbers go to international format, countries to codes, job titles to your role list and free text to your picklist values, so reports and routing rules see one spelling.
Task 06
Reconcile every night
A scheduled job compares owned fields across systems and reports what synced, what failed and was retried, what waits for review and which records still disagree.
Step trace
One run, step by step
Read the trace as text (Sample data)
- 00:00Form webhookStepContact form submitted with a work email, phone, company name and job title.
- 00:00NormaliserDonePhone put in international format, job title mapped to the role list.
- 00:01MatcherDoneNo shared id, but the normalised email matches one CRM contact exactly: an update, not a new record.
- 00:01Field rulesDoneJob title: the form may update it. Company name: owned by the CRM, so the form value is logged and skipped.
- 00:01Field rulesCheckPhone differs from a value a rep edited in the CRM this week. Rule: recent rep edits win, so hold the change for review.
- 00:02Review queueApprovalConflict shown to the ops owner with both values, both sources and both timestamps.
- 00:02CRM writerDoneRemaining fields written as one upsert keyed on the submission id, with before and after in the ledger.
- 00:03EnricherDoneIndustry and size band were blank. Filled from the approved source and stored with source and date.
- 02:00ReconcilerStepNightly run: the contact matches in both systems except the held phone field, listed under waiting for review.
Field ownership
Which system wins, field by field
| Field | Owner | Who else may write | On conflict |
|---|---|---|---|
| Your CRM | Forms, for new contacts only | Never overwritten. A different email becomes a second address or a review item. | |
| Phone | Your CRM | Forms, helpdesk | A recent rep edit wins; otherwise the newest value, with the old one kept in history. |
| Company name | Your CRM | Enrichment, when blank | The CRM value is kept and the difference appears in the nightly report. |
| Billing address | Billing system | Nobody else | Copied to the CRM. A CRM edit is flagged, never sent back. |
| Industry and size band | Enrichment | Your CRM, as a manual override | A value a person entered always beats enrichment. |
| Lifecycle stage | Your CRM | The lead routing workflow | Moves forward only. A move backwards needs a person. |
Merge preview
Two records matched on normalised email. The kept value and the reason are decided per field before anything is written.
Email
- CRM contact
- buyer@example.com
- Form submission
- Buyer@Example.com
Kept: buyer@example.comIdentical once normalised: this is the match key
Phone
- CRM contact
- Ends ••410
- Form submission
- Ends ••925
Kept: Held for reviewA rep edited the CRM value recently
Company
- CRM contact
- Example Logistics Pvt Ltd
- Form submission
- Example Logistics
Kept: Example Logistics Pvt LtdThe CRM owns company name
Industry
- CRM contact
- Blank
- Form submission
- Blank
Kept: LogisticsBlank field filled from the approved source, with its date
What the nightly report shows
One short message to the data owner each morning, linking to the full list.
- Records compared for each object, and how many agree on every owned field
- Writes that failed, how often each was retried and which are still queued
- Items waiting in the review queue, oldest first
- Records that exist in one system only, with the likely reason
- Fields that disagree, with example records so the owner can spot a pattern
Systems involved
What it connects to
- Your CRM
- System of record for contacts, companies and deals, through its API and a scoped service account.
- Forms and booking tools
- Sources of new and changed contacts, connected by webhooks.
- Billing or order system
- Owner of billing address, plan and payment status; read-only for the sync by default.
- Approved enrichment source
- A data provider or public register you choose, used within its limits and terms.
- n8n, Make or custom code
- Runs the sync, the queues and the retries, on accounts in your name.
- Supabase or your database
- Holds match keys, the change ledger and the review queue.
Guardrails
- Every field has one owner. A write from a system that does not own the field is logged and skipped, never applied silently.
- Merges happen only on exact key matches. Near matches, such as the same name at a different domain, go to a person.
- Enrichment fills blanks and never overwrites a value a person entered. Each enriched value keeps its source and date.
- Deletes never sync. A delete in one system becomes a flag in the other for a person to confirm.
- A bulk change above your threshold pauses the sync and alerts the owner, so one bad import cannot rewrite the CRM.
- The ledger keeps the before and after of every write, so any change can be traced and reversed.
Human checkpoint
An ops or RevOps owner works the review queue each day: near-duplicate merges, conflicts the rules cannot settle, deletes and bulk changes over the threshold. Each item shows both records, their sources and timestamps, and three choices: merge, keep both, or take one value. Every decision is logged, and cases that keep recurring become new rules.
What we plan for
Typical targets
Typical target
None from exact-key matches
Duplicate records created by the sync
Basis: Design property: writes are keyed on match keys and idempotency keys, and anything less certain goes to review instead of creating a record
Typical target
80–95% after tuning
Field conflicts settled by rule, without a person
Basis: Measured in a shadow run on your own records before go-live; what remains goes to the review queue
Typical target
Under a minute for webhook fields; overnight for enrichment
Time for a change to reach the other system
Basis: Event-driven sync where the tools send webhooks; enrichment runs on a schedule to stay inside provider rate limits
Rollout
Week by week
Week 1
Field inventory and the ownership table, agreed with the people who use each system. Read-only access and a sample export to measure duplicates and blanks.
Weeks 2–3
Normaliser, match keys and field rules built. The sync runs in shadow mode, writing only to the ledger, and we compare its decisions with your data.
Week 4
Review queue and nightly report go live, and one direction of the sync is switched on for one object, usually contacts.
Weeks 5–6
The second direction and the remaining objects, enrichment for blank fields, the bulk-change threshold and alerts. Runbook handed over.
FAQ
Frequently asked questions
Which system should be the source of truth for customer data?
Usually no single system is right for every field. The CRM tends to own contact and relationship fields, billing owns plan and payment data, and the helpdesk owns ticket history. We agree an owner per field with the people who use each tool, and the sync enforces it.
Can you clean up the duplicates we already have before the sync goes live?
Yes, and we usually start there. A one-off pass runs the same match keys over your existing records, merges exact matches by your field rules and puts the rest in the review queue. Every merge is recorded in the ledger with the before and after.
What counts as a duplicate, and who decides?
You do, in the first week, by ranking the match keys. Exact matches on strong keys such as a shared id or normalised email merge automatically; anything looser waits for a person, because a wrong merge is harder to undo than a missed one.
Where does enrichment data come from, and are we allowed to use it?
From sources you choose and are entitled to use: a data provider you subscribe to, a public company register, or your own past records. We check each source’s terms for automated use, store the source and date beside every value, and do not scrape personal profiles.
What happens if someone deletes a record in one tool?
The delete is not copied. The matching record in the other system is flagged for a person, who can archive it, keep it or delete it. Automatic deletes across systems are the quickest way to lose data nobody meant to remove.
Will the sync slow down our CRM or run into its API limits?
It should not. Calls are batched and kept under your plan’s published limits, a queue absorbs peaks, and backfills run outside working hours. When a limit is reached the sync waits and resumes; it never drops changes.
Can we change a field rule after launch without a developer?
Rules live in a configuration table rather than in code. Your ops owner proposes a change, it is replayed against a sample of records in shadow mode, and then it is switched on. On the Growth plan we make and test those changes for you.
Next step
Have a workflow in mind? Let’s scope it together.
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment