How to connect your business systems without replacing them

Start with the work between your tools

Your team should not have to become the connection between your software. When someone copies an approved quote into a job system, checks stock in a spreadsheet and then re-enters the customer in accounts, business systems integration is worth investigating.

You can often keep the tools that work and connect the handoffs around them. First, check what each tool lets an integration read or change. An existing connector may cover the task; a custom connection may be needed for your approval rules or exceptions. Some older tools only support file imports. These constraints shape the scope before anyone promises a seamless connection.

Choose one complete handoff, such as an approved quote becoming a draft job. Name its trigger, required information and finished result. Define how quickly it must happen: a stock update may need to be prompt, while a weekly report can wait. Agree what the team will see while an update is still pending.

A dependable integration does not need to move every field everywhere. It needs to move the right information to the right place, with enough context for someone to trust it.

Give each field one place to be corrected

“Keep everything in sync” leaves a difficult question unanswered: what happens when two systems disagree? Decide which system is authoritative for each field and where staff should make corrections. Other tools can display that information without gaining permission to overwrite it.

Here is a hypothetical business selling products and arranging installation. Its CRM, inventory tool and accounting system each have a different job. This example is a starting point for discussion, not a claim about a particular software setup.

Recognise the same customer, order and action

Names alone are unreliable record matches. Two customers may share a name; one customer may appear under several spellings. Keep a record of which CRM customer ID corresponds to which accounts contact ID. Orders and products need their own stable references too. Microsoft’s Dataverse guidance describes this principle through alternate keys: unique identifiers used to connect records across systems.

Clean up obvious duplicates before the first import. If a match is uncertain, put it in a review list. Automatically merging two similar names can be harder to undo than asking someone to confirm them.

Also distinguish the record from the action. A connection may create a draft invoice successfully, then lose the response. Retrying the creation without checking can create a second invoice. Ask your builder how the system recognises an action it has already completed.

Xero’s guidance on idempotent requests explains one form of protection against repeated processing, with limits that the integration must respect. Keep durable links to created records as well. Test repeated deliveries, delayed responses and an operator pressing retry; each should lead to the intended single result.

Make failed updates someone’s job

Connections fail for different reasons. A temporary outage may justify waiting and trying again. A missing customer reference needs a correction. Lost access needs someone to reconnect the account. Treating every failure as “try again” creates a growing queue of unresolved work.

Microsoft’s retry guidance makes the same distinction between temporary faults and failures that need another response. For your team, the practical requirement is an understandable exception list: which record is affected, what did not happen, when it last tried, who owns it and what to do next.

Show whether the destination changed before anyone retries. If an invoice exists but the job record was not updated, the recovery action should repair the missing link, not create another invoice. Keep enough history to explain what happened without making operators read technical logs.

Add reconciliation: periodically compare the records that should have arrived with those that actually arrived. A quiet error list does not prove that every order was delivered. Agree the comparison window and investigate missing or mismatched items.

For teams working across Australia, label dates and time zones explicitly. A timestamp without context can turn “updated today” into a disagreement between offices.

Use this checklist before expanding

Pilot one handoff with representative, authorised examples. Include a normal record, a correction, a cancellation, a duplicate and a failed connection. Have the people who use both systems review the finished result.

Use this checklist in a scoping meeting. A clear answer matters more than a confident demo.

• Ownership: can we name the source and correction point for every shared field?
• Matching: what identifies each customer, order and product, and who reviews uncertain matches?
• Permissions: can the connection access only the records and actions it needs?
• Timing: what delay is acceptable, and how will staff recognise stale information?
• Recovery: can we repeat an update safely and resolve failures without duplicating work?
• Reconciliation: how will we find records that never arrived or no longer agree?
• Operation: who monitors the connection, handles changes and keeps work moving if it stops?
• Evidence: does the complete handoff reduce re-entry and checking time without increasing corrections?