Before you connect two systems, decide which one is right

“Just connect them” sounds harmless enough.

The CRM has the customer. Xero has the invoice. The job system has the work. The booking tool has the date. Surely the systems can just talk to each other.

They can. But first someone has to answer a harder question. When two systems disagree, which one is right?

Integration moves truth around

An integration isn’t just a pipe between two tools. It moves business truth from one place to another.

Customer names, addresses, payment status, booking times, stock levels, job notes, approval states, invoice totals. Every one of those has consequences the moment it changes. If the integration sends the wrong value, updates the wrong record, or overwrites a good answer with a worse one, the mess spreads faster than it ever did when people were doing it by hand. Which is why source-of-truth decisions belong before the code, not after.

What it looks like when nobody decides

An equipment hire company in Toowoomba runs a CRM for the sales side and Xero for the money. A customer moves offices and gives the new billing email to their account manager, who updates the CRM and gets on with the day. Xero never hears about it. For the next two months every invoice lands in an inbox nobody reads, the statement follows it in, and the first anyone knows is a tense phone call about $14,000 in overdue invoices the customer swears they never received.

So the business connects the two systems, which sounds like the fix. Except nobody decided who owns the billing email. The new sync copies the CRM contact over the Xero contact every night, so the next time the accounts team corrects an address directly in Xero, the integration quietly puts the stale value back at 2am. The error now has an engine behind it. And notice that the pipe worked perfectly the whole time. What failed was a decision nobody made: when these two systems disagree about a customer, which one is right?

Decide ownership field by field

No single system has to own everything. Finance might own invoice status and payment dates. The CRM might own sales stage and the customer communication history. Operations might own job status, site notes and who is allocated to the job. A booking system might own the appointment time right up until the job is accepted, at which point the job system takes over.

Write those decisions down by field. Don’t let them get guessed at inside the integration. For each shared record, work out which system creates it, which system is allowed to update it, and which one wins when the values differ. Decide whether changes flow one way or both ways, which updates need a human to look at them, and what should never be overwritten under any circumstances. Those answers become the rules the integration follows.

Two-way sync is rarely as simple as it sounds

Two-way sync is tempting because it sounds fair. Both systems stay current, everyone sees the same thing.

In practice it creates hard problems. Two staff edit the same customer in different systems at the same time. A payment update lands after a status change and clobbers it. A record gets deleted in one tool but still exists in the other. One system enforces a stricter field format than its neighbour. Sometimes two-way sync is the right call. More often, one-way flow with a single clear owner is the safer one. You’re not trying to make the two systems equal. You’re trying to keep the data right.

Failure handling is part of the scope

Every integration fails eventually. An API times out. A token expires. A field changes shape. A vendor rate limit kicks in. A record turns up missing a required value. A staff member deletes something that another system still points at.

Here’s the ordinary version. The OAuth token to the accounting platform expires on a Friday afternoon. Nothing crashes and nothing alerts anyone; the sync just stops. By Wednesday there are a few hundred invoices sitting in the job system that Xero has never seen, and the BAS is due. Whether that’s a nuisance or a small disaster depends on decisions made long before that Friday. Did the failed records queue up for replay, or evaporate? Did an alert reach a person who still works there? And when the connection comes back, can the sync catch up without double-creating the invoices it already sent? “Safe to run twice” is a property you design in, not one you get for free.

So the question is never whether it will fail. It’s what happens when it does. Should the system retry, or queue the record, or alert a person? Create a task? Halt the whole sync, or let the rest carry on? Surface the failure in an admin screen, or roll it into a daily reconciliation report? If the honest answer to all of that is “nobody knows”, the integration is not ready to ship.

Reconciliation keeps people honest

The integration should be able to prove that the records that matter actually agree.

That doesn’t mean comparing every field every minute. Pick the records that carry risk and check them on a sensible rhythm: invoices, payments, bookings, job completion, stock adjustments, customer updates, whatever would hurt if it drifted. A weekly job that compares invoice totals between the job system and Xero and emails a human the handful that differ costs a day or two to build, and it pays for itself the first time it catches a sync bug before month-end instead of after. Reconciliation is what stops a small defect from turning into a month-end surprise. It also gives staff some confidence. They’re not left hoping the systems probably agree. They can see which records matched and which ones need a look.

Access and credentials deserve care

Integrations usually run through service accounts, API keys, OAuth apps or webhooks, and those credentials should be scoped tightly to the job. If an integration only needs to read customer details, it has no business being able to delete invoices. If it needs to write booking updates, it doesn’t need full admin access across the whole system.

Keys shouldn’t be sitting in the code. Shared staff logins shouldn’t be running production integrations. And the access should be documented, so the business knows exactly what is connected and how to switch it off safely if it ever has to. Security is part of integration work, not a bolt-on. The connection has to be safe to run.

Someone has to own it after go-live

Integrations don’t stay finished. Vendors version their APIs and retire the old ones, usually announced in an email to whichever address created the developer account five years ago. Fields get added. Rate limits tighten. One of the connected tools gets replaced, and the integration outlives the system it was built around. If nobody’s watching, the first symptom of any of this is bad data with a head start.

So name a person who owns each connection, and give them something to look at: a status page or a daily summary that says what synced, what failed and what’s waiting. Silence is what a dead integration sounds like, so build the connection to make noise. Budget a little ongoing attention too, because an integration is a live service, not a build you finish and forget. And when the person who set it all up resigns, the handover has to include the connections, the credentials and the documentation, or the business is one departure away from plumbing nobody can safely touch. The same instinct behind asking a vendor how you’d get your data back out applies here: know how the pieces connect before something forces you to find out.

Start with one valuable connection

The best integration projects start narrow. Pick the record staff copy between systems most often, or the report nobody trusts, or the handover that creates the most rework. Decide ownership for it. Connect the two systems, add logging, reconcile the result, and let staff actually use it. Then widen out from there.

Trying to wire every system together at once is how a useful project turns into a long, expensive argument about every field the business has ever invented. Start with the one link that gives you the clearest operational return.

Write the rules before the build

Before you commission any integration work, write down:

• The systems involved.
• The records and fields that need to move.
• The source of truth for each field.
• The direction of each update.
• The failure and retry rules.
• The reconciliation checks.
• The credentials and permissions required.
• The person who owns the connection after launch.

It doesn’t have to be perfect. It just has to drag the hidden decisions out into the open.

Rangefront Labs builds systems integrations and APIs for businesses that need CRM, finance, operations, portals and reporting to agree with each other. If you are mapping a project right now, the Systems Integration Requirements Worksheet is a good place to start, and for a common business pattern have a look at Xero, CRM and operations integration.

Connect the systems once the business has decided which facts matter, who owns them, and what happens when the tools disagree.