Operations & Reporting

Keep two systems in sync without a project

A scheduled reconciliation instead of a middleware build nobody has time for.

Time
16 minutes
You work in
Scheduled Jobs
Connect first
HubSpotGoogle Sheets

Before you start

  • Both systems connected
  • A decision about which one wins

Two systems holding the same information is a fact of life, and keeping them in agreement is usually treated as an integration project: a middleware tool, a mapping exercise, a thing on next quarter's list that never quite starts.

For most small businesses the honest requirement is much smaller. The two systems need to agree by the time somebody looks, not within a second.

Decide which system wins, per field

This is the entire design. Skipping it is why sync projects fail.

Not "the CRM wins". Per field: the CRM owns deal stage, the accounting system owns invoiced amounts, the product owns last login. Write it down, because every conflict you will ever hit is resolved by that document.

Anything you cannot assign an owner to is a field two teams both believe they control, which is a conversation rather than a technical problem.

Reconcile on a schedule, do not stream

Prompt
Every hour, compare [system A] and [system B] for the records that exist in
both.

For each field in our ownership document, if they disagree, update the
non-owning system to match the owner.

Report what you changed: the record, the field, the old and new values.

If a record exists in one system and not the other, do not create it. List
it for me.

If a field is empty in the owning system and populated in the other, do not
overwrite with the blank. Flag it.

"Do not overwrite with a blank" prevents the failure that destroys data. An empty field in the owning system usually means nobody filled it in, not that the value is empty. A literal sync propagates the blank, and the populated side loses information that existed nowhere else. This one rule is the difference between a sync you can run unattended and one you cannot.

Do not create records across the boundary

Updating a record that exists in both places is safe. Creating one is a decision about whether something belongs in that system at all, and automating it is how a CRM fills up with entries nobody meant to make.

List them and let a person decide, at least until you have watched the list for a month.

Read the change log for a fortnight

You are looking for churn: a field that changes back and forth every hour because both systems think they own it. That is an ownership document error, and it is invisible except in the log.

What good looks like

The systems agree, changes are logged, and nothing was built.

The measure is the flagged list. It should be short and boring. If it is long, the two systems disagree about more than fields — they disagree about what a record is.