Skip to content

Automation & Orchestration

Data synchronization: every field has one owner

Your CRM and your job system both hold the customer, and sooner or later they disagree. Data synchronization decides, field by field, which system owns the truth. Changes flow from the owner to the others, an edit made in the wrong place is put back and logged, and anything the rules can't settle goes to a person.
Discuss your systemSee who owns each field ↓
CRMM.D. · 9 Willow CtJob systemM.D. · 9 Willow CtCRM →phone · owner555-0181555-0199phone555-0181555-0199555-0123555-0199CRM →email · ownerm.d@example.comemailm.d@example.com← Job systemjob statusscheduledcompletedjob status · ownerscheduledcompleted← Job systemnext visitFri 08:00next visit · ownerFri 08:00CRM owns phone14:05 · phone edited in the job system · CRM owns it · restored 555-0199 · logged

Two copies of the truth drift apart

Most businesses keep the same customer in more than one system. A new phone number goes into one of them, a job update into another, and nobody is sure which copy to trust. Two-way syncs that copy everything everywhere make it worse: the last edit wins, wherever it came from.

Data synchronization starts by deciding ownership. Each field belongs to one system; changes flow outwards from there. Records are matched on agreed identifiers, conflicts are settled by rule and logged, deletions mean what you've agreed they mean, and a sync that fails retries in order without losing changes.

Who owns each field

Decided once, written down, and followed every time a value changes.
PhoneCRMCRMJob system
EmailCRMCRMJob system
Property addressJob systemCRMJob system
Job statusJob systemCRMJob system
Next visitJob systemCRMJob system
Sales notesCRMstays where it is

Three changes

One goes the usual way. Two show why the rules matter.

M.D. · phone changed in the CRM

  1. Change detected in the CRM

    10:02

    done

  2. CRM owns phone

    done

  3. Job system updated

    555-0199

    done

  4. Change logged

    done

The owner changed it, so it flowed out. Both systems agree within a minute.

Five decisions before anything syncs

  1. 01

    Which records

    Not everything

    Only the records both systems need, such as active customers, not every contact ever entered.

  2. 02

    Which owner

    Field by field

    Each field belongs to one system. Shared fields need an owner too, or they'll fight.

  3. 03

    How records match

    The same customer in both

    An agreed identifier, such as the CRM's customer ID stored in the job system, never a name.

  4. 04

    What wins a conflict

    By rule

    The owner wins; the other edit is logged and someone is told when it matters.

  5. 05

    What deleting means

    Archive, usually

    A record deleted in one system is archived in the others, not erased, unless you decide otherwise.

What data synchronization hands off

In

Changes
from each system
Ownership map
field by field
Rules
matching, conflicts, deletions
Sync
owner → others, in order

Out

Aligned records
in every system
Change log
what, where from, when
Conflicts
for a person, when it matters

Worth building when the same customer lives in two systems

Good fit

  • The same records are kept in two or more systems.
  • They disagree often enough that people have stopped trusting one of them.
  • You can say which system should own each field.

Not the right fit

  • One system could hold the data and the other could read it directly. Then don't copy it.
  • Nobody can agree which system owns what. Settle that first.

Where it's built in

Next to data synchronization

Questions about data synchronization

Can't we just turn on the built-in two-way sync?

Sometimes. Built-in syncs often let the last edit win, whichever system it came from. If that's acceptable for your fields, use it. If not, ownership rules are the difference.

How fast is it?

It depends on what each system allows. Where a system sends events, changes usually flow within moments; where it doesn't, a scheduled check picks them up.

What happens to records that already disagree?

A one-off reconciliation goes first: records are matched, differences listed, and the owner's values applied, with the cases that need a decision sent to a person.

What do you build it with?

Often n8n or Trigger.dev for the sync logic, with PostgreSQL holding the ownership map, match keys and change log. These are starting candidates, not requirements.