Skip to content

Business Operations & Automation

Cross-system sync: one ledger for every change between your systems

Your field service tool, accounting, CRM and customer portal each hold part of the same customer, and each was connected to the others on its own. A sync layer gives every shared field one owner, records every change with where it came from and where it went, and holds a conflicting change for a person instead of letting it overwrite the right value. We connect the systems you already run, field by field.
Talk through your systemsSee who owns what ↓
Field serviceowns: jobs, addressesAccountingowns: billingCRMowns: contactsCustomer portalowns: requestsSync layerownership rules · ledgerLedger · today09:02Phone numberappliedCRM → field service, accounting09:14Invoice paidappliedaccounting → field service, portal09:20Job closedappliedfield service → accounting, portal09:31Service addressconflictportal ≠ field service→ office lead

Every connection was added on its own

Most businesses connect their systems one pair at a time: the CRM to the job tool, the job tool to accounting, the portal to whatever it needed. Each connection copies what it was set up to copy. Nobody decided which system is right when two disagree, so the last write wins, and nobody can say where a wrong value came from.

A sync layer sits between the systems instead. Each shared field has one owner. A change from the owner flows to every copy; a change from anywhere else is held as a conflict for a person. Every change is written to a ledger with its source, its destinations and its result, so a wrong value can be traced and put right.

Today, and with a sync layer

Today

  1. 01Each pair of systems is connected separately.
  2. 02Whichever system writes last wins.
  3. 03A failed sync is noticed when a customer complains.
  4. 04Nobody can say where a wrong value came from.

The customer's new address reaches the invoice but not the technician.

With a sync layer

  1. 01Every system connects once, to the layer.
  2. 02Each shared field has one owner.
  3. 03A change from anywhere else is held for a person.
  4. 04Every change is in the ledger, with its source and result.
  5. 05Failed deliveries are retried and shown, not lost.

When two systems disagree, someone decides, and the ledger shows who.

One owner for every shared field

Phone and emailCRMField service, accounting, portal
Service addressField serviceCRM, accounting, portal
Job status and next visitField serviceCRM, portal
Invoices and paymentsAccountingField service, portal
Customer requestsCustomer portalField service
Sales notesCRMStays in the CRM

How it fits together

Cross-system sync takes changes from your field service tool, accounting, CRM and portal, records each in a ledger, checks which system owns the field, and sends changes from the owner to every copy. Ownership rules are agreed with you and applied to every change, and conflicts go to a person to decide. It produces copies that agree, conflicts queued instead of overwritten, and a ledger of every change with its source and result.

What changes from one business to the next

SystemsWhich systems take part, and which stay out
Shared fieldsWhat's copied between them, and what stays home
OwnersWhich system is right for each field
ConflictsWho decides, and how quickly
TimingWhich changes move at once, and which wait for a nightly run

A common starting point is n8n or Trigger.dev receiving changes by webhook and API, with the ledger and ownership rules in PostgreSQL and a small review screen for conflicts. These are starting candidates, not requirements.

Is a sync layer the right fit?

Good fit

  • Three or more systems hold copies of the same customers and jobs.
  • Values disagree between systems and nobody knows which is right.
  • The systems need to stay, because each does its job well.

Avoid when

  • Two systems, a few fields. A direct sync is simpler.
  • The systems could become one. Consider a workflow platform first.

How we'd approach it

Most of the early work is listing the systems and shared fields, who owns each, and how conflicts are settled.

  1. 01

    Understand

    As much as the problem needs

    We map how the work runs today: who does what, which systems hold the records, and where it breaks.

  2. 02

    Design

    Decided before it's built

    Ownership, rules, integrations and exceptions, agreed with you and written down with acceptance criteria.

  3. 03

    Build

    Connected to what you use

    We build the scoped system, connect it to the tools you already run, and test it on the cases that matter.

Related systems

The capabilities underneath

Questions about cross-system sync

What if a system doesn't send changes?

The layer checks it on a schedule instead and compares what's changed since last time. It's slower, and the ledger shows which changes came that way.

Can the owner of a field change later?

Yes. It's a rule, not code, so moving ownership is a change you approve, recorded like any other.

What happens when a system is down?

Changes for it wait in the layer and are delivered when it's back, in order. The ledger and the command center show what's waiting.

Can conflicts be settled automatically?

Some can, by rule, such as the newer value winning for a field you say is safe. Anything else waits for a person, because the right answer depends on the business.

Make your systems agree

Tell us which systems hold the same customer today and where they disagree. We'll show you which field each should own.

Start a project