Practical guide / Business systems
Before you connect two business systems.
A useful integration brief explains the business process as well as the data connection. Work through these questions with the people who own the process, the systems and the day-to-day work.
1. Name the job that needs to get done.
“Connect the CRM to the reporting platform” describes a technical connection. “Give the sales manager an agreed account view before the weekly review” describes the job it needs to support.
Write down who needs the result, when they need it and what they will do with it. Pick one real example and follow it from the first input to the final decision.
Put in the brief: the process, the person using the result, the current difficulty and a practical sign that the work has improved.
2. Decide which system owns each fact.
For every field that matters, identify where it is created and which system is allowed to change it. Agree how the same customer, account or case is identified in both systems.
An account name is often a poor join key. Consider duplicate names, renamed organisations, merged records and the effective date of a change. The people who own the data need to help settle these rules.
Put in the brief: identifiers, source of truth, update direction, required fields and rules for conflicts or missing values.
3. Design the exception path.
Ask what happens when a required value is absent, a record is rejected or one system is temporarily unavailable. Someone needs to know whether the work is delayed, failed or complete.
Decide how an exception is surfaced, who can correct it and whether the operation can safely be retried. For a repeated submission, establish how the system avoids creating a duplicate result.
Put in the brief: failure states, notifications, retry rules, manual correction and the owner of unresolved work.
4. Make access and data handling explicit.
List the data the integration actually needs and the people or services that require access. Agree separate access for development, testing and live operation where the systems support it.
Identify any external services involved and the organisation’s requirements for using them. Bring security, privacy or other specialists into the decision where their input is needed.
Put in the brief: access owners, environments, required permissions, external services and the approvals needed before live use.
5. Agree what a successful test looks like.
“The API responds” is only one check. Test whether the person at the end of the process receives the right result, at the right time, with enough information to complete their work.
Use normal cases, incomplete records, corrections, duplicate submissions and service interruptions. Include the people who will accept the business result.
| Example | Question to answer |
|---|---|
| A new account | Is it created once, with the right owner and required information? |
| A change of ownership | Does it take effect at the agreed time in each relevant system? |
| A rejected record | Can the responsible person find, understand and correct the issue? |
| A repeated submission | Does a retry avoid creating duplicate work? |
| An unavailable system | Is work held, retried or routed for attention in the agreed way? |
On a small screen, scroll across to see every column.
6. Separate the first release from the full rollout.
A useful first phase is small enough to understand and real enough to test the operational assumptions. Agree which team, process or subset of records is included.
Before expanding to more business units or countries, revisit local definitions, access, ownership and training. A wider rollout can introduce new requirements even when the software is the same.
Put in the brief: first-phase scope, acceptance owner, rollout dependencies and the decision required before expanding.
7. Give the live process an owner.
Decide who will watch for failures, approve changes, maintain access and answer operational questions. Documentation should explain both the technical connection and the business process it supports.
Agree the support arrangement before launch. A small allowance for planned improvements and a business-critical incident response service are different commitments.
Put in the brief: operating owner, documentation, training, monitoring responsibility and the support arrangement.
A concise brief to bring to the first conversation.
If several of these answers are unknown, a bounded assessment can establish the decisions and options before a full build is quoted.
What happens today?
One process, one example and the systems it passes through.
What should change?
The business outcome and how the relevant person will recognise a useful result.
Who needs to be involved?
Process owner, system owners, users, suppliers and any specialists needed for the decision.
What is already fixed?
Timing, access, existing work, contractual constraints and the budget available to investigate the next step.
A useful next step
Want to work through the brief together?
Tell me about the process and the systems involved. The first conversation is 30 minutes and free.
No VAT added — I’m not VAT registered.
View the full engagement terms.