To integrate business applications, work through nine steps for one link: list the applications and their owners, map what moves, agree formats, set up access, plan for failures, build the link, test it, monitor it and hand it over. Each step has an owner and a named output.
Last reviewed 2026-11-05 by Manish Sharma.
Connecting applications means one application passes records or events to another without anyone retyping them. Moving data for analysis into a warehouse is a different job than connecting applications. This guide is for a team that has already decided to go ahead. It covers linking the applications a business runs on, one link at a time. It leaves out what unlinked applications cost a business, and the choice of method gets one line in step 6.
Build Order to Integrate Business Applications at a Glance
The table gives the sequence, and the sections take each step in turn.
| Step | Owner | Output |
|---|---|---|
| Step 1: List the applications and who owns each | Business owner | A one-page list of both applications with named owners |
| Step 2: Map what moves between them, and when | Application owner of the sending side | A map of each hand-over with trigger, volume and manual step |
| Step 3: Agree record formats and field names | Both application owners | A signed field list naming each record’s source application |
| Step 4: Set up access for the link | Security lead | An access record with identity, permissions, credential holder and review date |
| Step 5: Plan for failures | IT lead with the support lead | A failure plan for each failure type |
| Step 6: Build one link | IT lead | A working test link, with the approach and its reason |
| Step 7: Test the link | Application owners with a business user | A test record of what the team tried, what happened, what the team fixed and who accepted |
| Step 8: Monitor the link | Support lead | A monitoring plan with alerts and review dates |
| Step 9: Document the link and hand it over | IT lead, then the support lead | A handover pack signed by the receiving owner |
Each Owner label names the person who looks after that function: the business owner answers for the process the link serves, the application owner for one application, the IT lead for the build, the security lead for access and the support lead for the link when it is live. A smaller firm can give two or three roles to one person; the named owner and the named output matter more than the title.
Step 1: List the Applications and Who Owns Each
Before you integrate business applications, name the two applications for this link. Then name the person who owns each and the business owner who signs off the link. Start from the business hand-over, such as an order that moves from sales to finance.
When you list each application, write down where it runs (on the firm’s own servers or as a hosted service) and who can change it. Then list the other applications that depend on it. One change to an application can reach several flows. A dependent you miss now turns up as a surprise later.
Keep the list to one page; it is the first document in the handover pack at step 9.
Owner: business owner; output: a one-page list of both applications with named owners.
Step 2: Map What Moves Between Them, and When
Write each hand-over as one sentence: this record or event leaves this application, reaches that one at this moment, and a person does this by hand today. That sentence shows the manual step the link will remove.
For each hand-over, record four things.
- The trigger, such as a completed order, a changed status or a daily run.
- The expected volume, including the busiest day of the month.
- The response time the business needs, from instant to next morning.
- The records to skip, such as drafts or cancelled orders.
Stay on records and events. Reports and figures belong to a different job. Volume and peak times matter here, because the other application may cap the requests it accepts each minute or day. Check its documentation for the figure and compare it with your busiest day. Step 5 then plans for that limit.
Start with one routine hand-over and write its sentence. If a colleague can read it and name the manual step, the rest of the map follows the same pattern.
Owner: application owner of the sending side; output: a map of each hand-over with trigger, volume and today’s manual step.
Step 3: Agree Record Formats and Field Names
Both application owners sign the same list of fields before anyone builds. Otherwise each side guesses, and the guesses differ.
Cover these points on the list.
- Only the fields each side needs.
- The same field under different names, such as “customer code” in one application and “account ID” in the other.
- Units, dates, currency and number formats.
- The source application for each record, when both can change it. Unless the owners name one source, the two applications overwrite each other.
A response can also arrive in a different type than expected, such as text in place of a number. That difference can break a link. Put each expected type on the list, and test it later at step 7.
Owner: both application owners; output: a signed field list with the source application named for each record.
Step 4: Set Up Access for the Link
Three decisions make up access for the link: its identity, its permission and who holds the credentials.
A link that runs on a person’s login stops working when someone disables that account or changes its password. Create an identity for the link instead.
Set the permission to read-only when reading is enough. Store the credentials in a secrets store or the firm’s existing vault. Keep them out of code and shared documents. Write down how they change when someone leaves. Note any expiry date too, since tokens and keys can lapse and stop the link. Use separate credentials for the test setup and the live link. Switch on an audit log so that you can trace every record the link touches.
The firm’s own data-handling rules and the rules that apply to its data affect what may be moved, stored and logged. Ask whoever looks after those rules before step 6, and take specialist advice for anything beyond that.
Owner: security lead; output: an access record with identity, permissions, credential holder and review date.
Key Takeaway The link needs its own identity, the least permission that works and one named holder for the credentials.
Step 5: Plan for Failures Before They Happen
A record that does not arrive needs an answer before anyone builds. Retries, queues and alerts are design decisions; adding them after the build means rework.
Plan retries, error handling and version control with roll-back as part of the design. The plan answers five questions.
- How many times does the link retry, and how long does it wait before the next try? Retry only temporary faults, such as a timeout or a “too many requests” reply. Lengthen the wait after each try. A record rejected for bad content goes to the holding place at once, because another try gives the same answer.
- Where does a record wait when every retry fails?
- What do the timeouts and rate limits of the other application allow?
- Who hears about a held record, and who fixes it?
- How does the link replay a held record after you fix the fault?
A retry can create a duplicate, such as a second order. To prevent that, each record carries a unique reference, and a retry sends the same reference again. The receiving application recognises the repeat and ignores it. If an application does not support this, the failure plan says which steps are safe to repeat and which need a check first.
Owner: IT lead with the support lead; output: a failure plan that lists, for each failure type, what the link does, who gets the alert and who fixes it.
Key Takeaway Decide before the build what happens to a record that does not arrive, and put the answer in the failure plan.
Step 6: Build One Link to Integrate Business Applications
Pick one approach, write the reason down, and build only the first link. The approach can be a direct link, middleware or a hosted platform. The owners make that choice and record it, but this guide does not compare them. To make that choice, work through questions and decision rules for choosing an approach, with a trial on one real link.
Build the smallest useful flow first, for example only completed orders. A small first link shows whether the field list and the access record hold up. Add the next flow when the first one works.
Keep the work under version control so that the team can roll a change back. Apply the skip rules from the step 2 map. Then follow the failure plan from step 5 in the code or the settings.
Do not connect every application in one project. Each extra link adds its own owners, formats and failure cases. A problem in a wide first release is harder to trace than one in a single link.
Owner: IT lead; output: a working link in a test setup that follows the failure plan, with the approach and its reason written down.
Step 7: Test the Link Before It Carries Live Records
Test in a separate setup with made-up or masked records. Do not copy live personal records into the test setup, in line with the data-handling rule from step 4.
Run these tests, and write down each result.
- Single rules, such as one field mapped correctly.
- A whole order from start to end, including every hand-over on the map.
- A partial failure, such as one of the two applications being unavailable.
- A duplicate, to confirm the receiving application ignores it.
- A record in an unexpected format, such as text in a number field.
- A user with too little permission.
- A batch the size of your busiest day.
A business user tries the result, then accepts it or sends it back. The IT team alone does not make that call.
Put a cancelled order, a duplicate and a record with a missing field in the test records. They exercise the failure plan from step 5 and the skip rules from step 2.
Owner: application owners with a business user; output: a test record of what the team tried, what happened, what the team fixed and who accepted.
Step 8: Monitor the Link After Go-Live
Watch both the link and the business result. A link can run and still lose records, which a technical status alone does not show.
On the link side, set up a status view, an error count and an audit log. Send alerts to a named person’s role and to a named backup, which covers holidays. Alert on a record count that falls to zero or far below a normal day, as well as on errors. A silent stop raises no error. Schedule a review of the field list and the access record, because both drift as the applications change.
On the business side, check whether each day’s orders reached finance and whether supplier invoices match goods received. These give a second warning when the technical view looks fine.
Owner: support lead; output: a monitoring plan with what the team watches, who gets the alert and the review dates.
Step 9: Document the Link and Hand It Over
Keep one central record of what the link does, why it exists, how the team built it and who to call. The record is what lets a new colleague take over without the builder.
Work through the handover in four moves.
the map, the field list, the access record, the failure plan, the monitoring plan and the steps to roll back.
the person who approves changes, and the person who acts when a connected application changes its interface.
this covers a leaver.
the IT lead gives the pack to the support lead, who signs to confirm they can run the link from it.
Owner: IT lead, who hands over to the support lead; output: a handover pack signed by the receiving owner.
Set-Up Mistakes When You Integrate Business Applications
Each set-up mistake traces back to one step, and the fix sits in that step. The table lists seven of them, each with its fix, as a way to check your own plan.
| Mistake, by step | Fix |
|---|---|
| Step 1: One side has no named owner | Name an owner for each application before any mapping starts |
| Step 2: The map covers only the smooth path | Add the cancelled, changed and late records as well as the smooth path |
| Step 3: Two applications can change one record when no source is named | Name one source application for each record before anyone builds |
| Step 4: The link runs on a person’s login | Create an identity for the link instead, and name one credential holder |
| Step 5: Nobody has decided what happens to a held record | Write the replay steps and their owner into the failure plan |
| Step 6: The team builds every link at once | Build the smallest useful flow first, then add the next one when it works |
| Step 8: Alerts go to a shared inbox nobody owns | Send alerts to a named role, and name a backup for holidays and leave |
This guide covers one link; choosing a method and checking readiness are separate jobs.
Signisys provides application integration work. Read this guide as a provider’s view. The way we approach linking your systems sits on the use case page, and the analytics and integration solution and data, analytics and AI service pages describe the wider offer.
How to Integrate Business Applications FAQ: Questions Answered
How do you integrate business applications without a big project?
Who should own the link once it is live?
What should you write down before you integrate business applications?
How many links should you build first?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.