The Integration Onion: 12 Layers for Integrations That Improve Business Processes and Remain Manageable
Connecting applications is not the same as integrating processes.
An API connection can work perfectly well from a technical perspective, while employees still have to correct data, enter the same information more than once or resolve errors manually.
That is why successful application integration does not start with the API. It starts with the question: Which business process do we want to improve, and what business value should the integration deliver?
For example:
- less manual data entry and fewer corrections;
- fewer errors;
- faster processing of customer data, orders and changes;
- consistent data across different applications;
- less employee capacity spent on repetitive tasks;
- better communication with customers, suppliers and other stakeholders;
- greater control over processes and exceptions.
Only then does the technology follow, in a structured way.
In this blog, we use the analogy of an onion to examine application integration layer by layer. We peel back 12 layers, from objectives and process analysis to APIs, data mapping, error handling, monitoring and management.
What is application integration?
Application integration is the process of connecting systems and applications, that were originally designed independently, enabling them to automatically exchange data and functionality with one common objective:
To work efficiently as one connected ecosystem within the organisation’s unique business process.
For example, an e-commerce platform can automatically send a new order to an ERP system. The ERP processes the order and inventory and can handle invoicing. Relevant order and delivery information then flows automatically to the WMS for logistics fulfilment. Once the order has been shipped, the WMS can return Track & Trace information to the ERP, the e-commerce platform and any other relevant systems.
The order processor no longer has to manually copy data from system A to systems B and C. This saves time, reduces the risk of errors and ensures that the systems involved have access to current and consistent information.
A robust integration, however, goes beyond simply connecting A to B. It supports the complete business process from A to Z.
That is precisely the principle behind the Fluxygen integration platform. The focus is not on isolated point-to-point connections, but on the interaction between applications, data flows and workflows.
We take business rules, dependencies and exceptions into account: Which data is leading? When should the next process step start? And what should happen when something does not go according to plan?
The result is not merely a technically connected application landscape, but an integrated business process in which systems work together, data is automatically updated at the right moments, and you and your employees remain in control.
Why is an API alone not enough?
An API tells you which data an application can technically receive or make available.
What an API does not automatically tell you is:
- which application should be the leading system;
- when data should be exchanged;
- which business rules apply;
- how fields in different systems correspond;
- what should happen when information is missing;
- how duplicate records should be prevented;
- what should happen when a system is temporarily unavailable;
- who should take action when a process gets stuck.
That is why we use the Fluxygen iPaaS to build integrations layer by layer.
Layer 1 — Define the desired business outcome
Do not start with:
Which APIs can we connect?
Start with:
What should demonstrably improve once the integration is in place?
For example:
- process orders faster;
- onboard customers faster;
- eliminate duplicate data entry;
- reduce manual corrections;
- synchronise inventory more reliably;
- make information available faster;
- give employees more time for meaningful tasks instead of repetitive work.
This step prevents you from building a technically interesting connection without first establishing a clear business objective.
A practical question 🤔
Before you start building, can you briefly explain which process improvement the integration should deliver?
If the answer is no, it is probably too early to start building.
Layer 2 — Explore the available integration options
At this stage, we investigate how the applications can be accessed technically.
An API is the obvious choice in many situations, but it is not the only option. Depending on the application, webhooks, files or batch exchange via SFTP may also play a role.
Older legacy systems or specific on-premises applications may require alternative integration methods.
The technical approach should therefore follow from the IT landscape and the requirements of the process.
Not the other way around.
Layer 3 — Study the API documentation
An API without good documentation is like a puzzle without the picture on the box.
So do not just look at what an API can do. Pay particular attention to its conditions and limitations, including:
- available endpoints;
- authentication methods;
- required and optional fields;
- data types;
- pagination;
- rate limits;
- error codes;
- webhooks;
- version management;
- limitations when processing large volumes of data.
For example, an integration may perform perfectly well in a test involving ten records, only to run into API limits when processing thousands of transactions.
You obviously want to identify these limitations before implementation.
Layer 4 — Arrange and test credentials
API access requires authentication.
This may be relatively straightforward using an API key, but it can also involve tokens, OAuth or additional authorisation procedures.
That is why access should be tested early in the project.
Do not only check whether authentication succeeds. Also verify that the credentials actually provide access to the required data and functionality.
This prevents the integration design from running into missing permissions later in the process.
Layer 5 — Map the processes and functional areas
We now shift the focus from technology to the business process.
Which data and process steps actually need to move between the applications?
For an e-commerce integration, these could include:
Product data
Product information is made available from the source system to other applications.
Inventory and prices
Current stock levels and prices are automatically synchronised.
Sales orders
Orders are transferred from an e-commerce platform, marketplace or OMS to ERP or logistics systems.
Deliveries
Delivery statuses are communicated back to the relevant systems.
Track & Trace
The carrier and tracking code are automatically made available to other systems and to the customer.
This illustrates an important point: what appears to be a single “connection” often consists of several separate data flows in practice.
Layer 6 — Understand how the applications actually work
API documentation alone is not enough.
Walk through the actual process in both applications.
- Which fields does the user see?
- Which data is mandatory?
- When is an order number generated?
- When is a customer record created?
- Which statuses change during the process?
This helps identify differences between the user interface, the data model and the API.
Where useful, take screenshots during the analysis and document which fields correspond functionally across the applications.
This provides a practical foundation for data mapping.
Layer 7 — Define business rules and exceptions
In practice, this is one of the most underestimated aspects of application integration.
Suppose an order needs to be transferred from an OMS to an ERP system.
Questions may arise such as:
- Does the customer already exist?
- How do we determine that?
- What do we do if the same customer uses different email addresses?
- Which delivery address is leading?
- Do we create a new address or update the existing one?
- What happens in the case of a partial delivery?
- Which price takes precedence when discounts apply?
- What happens when essential information is missing?
Technology and AI can support or automate these decisions, but the organisation must define the business rules and remain accountable for them.
Business rules determine how the integration should behave in the real world.
Layer 8 — Create the data mapping
Different systems can use different names for the same thing.
The same piece of information may be named, stored or interpreted completely differently in two applications.
A product number, for example, may be called ItemCode in one system and SKU, ProductID or something entirely different in another.
Data mapping therefore determines:
- which source field corresponds to which target field;
- which transformations are required;
- which values are mandatory;
- which identifiers are unique;
- how formats should be converted;
- which system owns which data.
Good mapping prevents technically correct data from producing functionally incorrect information.
Layer 9 — Build the integration flows
Only now do we arrive at actually configuring and building the integration.
In a Low-Code iPaaS such as Fluxygen, individual steps are built as flows.
For example:
- authenticate;
- retrieve new orders;
- check whether the customer already exists;
- create missing data;
- transform the data;
- map the order lines;
- send the order to the ERP;
- validate the result;
- return status information.
Building processes in a modular way makes individual components easier to manage and, where possible, reusable.
Layer 10 — Design error handling, logging and recovery
An integration is not well designed if only the happy flow works.
What happens when:
- an API is temporarily unavailable;
- authentication expires;
- a rate limit is reached;
- mandatory data is missing;
- a record is rejected;
- a process stops halfway through;
- the same transaction is submitted again?
Error handling should therefore always be part of the integration design.
Depending on the process, an integration may retry automatically, isolate a transaction for further processing, generate an alert or stop in a controlled manner.
Logging and monitoring then make it clear what happened and where action is required.
That is the difference between a connection that works only when everything goes according to plan and an integration that a business process can genuinely rely on.
Layer 11 — Measure and optimise
Going live marks the beginning of a new phase.
Experience shows that users do not always report inefficiencies or bugs in a process. Sometimes they simply solve the problem themselves using Excel, manual corrections or their own workarounds.
Technically, the integration may appear to be working properly, while new manual tasks have quietly emerged within the process.
That is why it is important to periodically ask questions such as:
- Where are employees still intervening manually?
- Which errors occur repeatedly?
- Which flows take longer than expected?
- Where do exceptions arise?
- Which data still needs to be corrected?
- Which process steps could be automated further?
Integration is not a one-off project. It is a continuous process of measuring, understanding, learning and improving.
Layer 12 — Organise management and change
Cloud applications never stand still.
APIs change, software vendors release new versions, business processes evolve, and organisations add new systems, customers or sales channels.
That is why management should be part of the integration architecture from the outset.
Consider:
- monitoring;
- logging;
- version management;
- API changes;
- security and authorisations;
- performance;
- capacity;
- incident handling;
- documentation;
- controlled changes.
A stable integration therefore needs more than a solid initial build. It must also be properly managed and able to evolve over time.
Practical example: integrating Exact Online with Hyarchis
A concrete example is the integration between Exact Online and Hyarchis Compliance Manager, which has been put into production at Lunenburg Administratie- en Advieskantoor.
When customer information changes in Exact Online, the integration ensures that the relevant data is automatically processed in Hyarchis. This involves more than simply transferring data: the integration retrieves the correct information, identifies existing relationships and checks whether processing has been completed successfully.
The result is less manual data entry, more up-to-date customer information and more time for work that genuinely adds value.
Paul Lunenburg describes the value as follows:
“By designing processes intelligently and efficiently, the system gives us peace of mind and a clear overview.”
That is precisely what good application integration is about: not the connection itself, but what it enables for the organisation and its employees.
Read the full case study:
How do you integrate Exact Online with Hyarchis Compliance Manager?
What does a well-designed application integration deliver?
When processes, systems and data are properly aligned, business value is created at several levels:
- manual data transfers disappear;
- fewer errors need to be corrected;
- information becomes available faster;
- employees spend less time switching between applications.
It also creates a foundation for further process automation.
Therefore the objective is not to connect as many systems as possible.
The objective is to make your unique business process work smarter while your organisation retains control over data, exceptions and change.
Integration is complex, but it does not have to be difficult
The original analogy still applies: application integration is like peeling an onion.
Underneath each technical layer lies another process, data or business question.
Those who start directly with the API often discover important process, data and business issues only during development — when changes require more time, money and development capacity.
Those who first understand the desired outcome, the process, the data and the exceptions can build far more effectively.
Fluxygen supports organisations from initial analysis through to stable integration flows in the cloud. With a Low-Code approach, processes and applications can be integrated and automated while the organisation retains control over further development.
Want to find out where manual work, duplicate data entry or unnecessary transitions between systems can be eliminated in your processes?
Map one specific process with us. It usually becomes clear quite quickly where integration can create real business value — without shedding tears while peeling the integration onion.
