Application integration: connecting ERP, CRM and e-shop without the spaghetti

A typical growing company runs an ERP for invoicing and stock, a CRM for sales, an e-shop, a courier platform and an accounting firm that wants exports every month. Each system is fine on its own. The trouble is between them: orders re-typed from the e-shop into the ERP, customers that exist with three different spellings, stock that is “available” online but sold out in the warehouse.

Application integration is the work of making these systems exchange data reliably, without people in the middle. This guide covers the building blocks, how to tell whether a script is enough or you need a platform, the mistakes we see most often, and how to compare the tools. If you are new to integration platforms in general, start with our introduction What is iPaaS, and when does a Greek business need it?.

From spaghetti to a managed integration layer

Most companies start with point-to-point connections. The e-shop plugin writes orders straight into the ERP database. A script exports customers from the CRM every night. An Excel macro uploads price lists. Each connection was a sensible decision at the time.

The problem is the total. With five systems you can end up with ten or more connections, each built differently, each with its own credentials, logging (or none) and failure behaviour. When the ERP is upgraded, nobody is sure which of them will break. When an order goes missing, nobody knows where to look.

An integration layer changes the shape of the picture. Systems connect to one place, the logic of each flow lives there, and monitoring, errors and credentials are handled consistently. That layer can be an integration platform, a set of cloud services or well-organised custom code. What matters is that it is one layer with one set of rules.

The building blocks

Whatever tool you use, every integration flow is made of the same parts.

1. Connectivity

Getting data in and out of each system: REST and SOAP APIs, database connections, files on SFTP, email, or a vendor-specific connector for the ERP or CRM. Good connectors save weeks, because they already know how the target system handles authentication, paging and its own quirks.

2. Triggers

What starts a flow. It can be a schedule (every five minutes, every night), an event (a webhook from the e-shop when an order is placed) or a request (an API call that needs an answer now). The trigger shapes a lot of the design, because a nightly batch and a real-time webhook fail in very different ways.

3. Transformation and mapping

The e-shop calls it billing.vat_number, the ERP calls it AFM, and the CRM keeps it in a custom field. Mapping turns one system’s data into the shape and codes another system expects: field names, formats, units, VAT categories, payment methods. This is usually where most of the business logic lives.

4. Orchestration and routing

Real flows have steps and decisions. Check whether the customer exists, create them if not, then create the order, then reserve stock. Route B2B orders to one ERP series and retail orders to another. Orchestration is the logic that ties those steps together in the right order.

5. Error handling

Systems are down for maintenance, APIs time out, a product code doesn’t exist in the ERP. A production flow needs a plan for each case: retry what is temporary, park what needs a human, and tell someone. We cover this in depth in Error handling and retries in Boomi integrations.

6. Monitoring and operations

You need to know what ran, what failed and why, without reading log files on a server. Dashboards, alerts, the ability to re-run a failed document, and an audit trail of what was sent where.

Do you need a platform?

You probably do if several of these are true:

You have more than three or four systems that need to share data, or plan to add more.
Integrations are business-critical: orders, invoices, stock or payments depend on them.
The person who wrote the current scripts has left, or would like to.
You find out about failures from customers or from the accounting department, not from an alert.
You need to connect cloud applications with systems that run on-premises.

You probably don’t yet if you have one or two simple, low-volume connections that rarely change, or if a native connector between the two applications (for example the ERP vendor’s own e-shop plugin) already does what you need and is supported. In that case keep it, document it, and make sure someone gets notified when it fails.

Common mistakes

Writing straight into the ERP database. It works until the next ERP update changes a table, or until the ERP’s own business rules (numbering, stock reservations, VAT) are skipped. Use the ERP’s API or import mechanism.
No idempotency. If a flow is retried after a timeout and creates the same order twice, you have a worse problem than the original failure. Every create operation needs a way to recognise “I have already done this”. See Syncing e-shop orders to your ERP with Boomi for a worked example.
Silent failures. A flow that logs an error and moves on, with nobody watching, is a data-quality problem waiting to be discovered at month end.
Business logic scattered everywhere. A bit of logic in the e-shop plugin, a bit in a script, a bit in an ERP trigger. Decide where each rule lives, and keep integration logic in the integration layer.
No shared codes. If each flow invents its own mapping for payment methods or VAT categories, they will drift apart. Keep code lists in one place.
Ignoring volume. A flow that handles 50 orders a day can collapse on Black Friday. Test with realistic peaks.

How to compare tools

Before looking at products, answer these questions:

Which systems must you connect? List them, with versions. Check for supported connectors for your ERP, CRM and e-shop, especially for local or less common ERPs.
Where do they run? If some systems are on-premises, you need a runtime that can reach them without opening the firewall to the internet.
Who will build and maintain the flows? Developers, IT generalists or business users. Low-code tools widen the pool of people who can help, but complex flows still need integration skills.
How critical and how heavy is the traffic? A few hundred records a day or hundreds of thousands. Real-time or batch.
How are errors and monitoring handled? Ask to see a failed execution, how it is reported and how it is re-run.
What is the pricing model? Per connection, per flow, per task, per runtime or per volume. Model it with your own numbers, including growth.
What else will you need soon? APIs, EDI with partners, master data, workflows. One platform that covers the next step can save a migration later.

Tools in this space

There is no single best tool, only a better fit for a given situation. These are the options we come across most often, in alphabetical order.

Azure Logic Apps. Microsoft’s workflow-based integration service, with a large connector library and pay-as-you-go or dedicated hosting options. A natural fit for organisations already on Azure and Microsoft 365, especially when combined with other Azure services such as Service Bus and API Management.
Boomi. A low-code integration platform where flows are built visually as processes and run on a runtime that can be hosted by Boomi or installed on-premises, which helps when the ERP is inside the company network. Beyond application integration it covers APIs, EDI, master data and workflows on the same platform. It fits best when you have a mix of cloud and on-premises systems and want one place to build and monitor everything.
Custom code. Scripts or small services in Python, .NET, Node.js or similar. Full control and no licence cost, and sometimes the right answer for one or two well-defined connections. The cost shows up later in monitoring, error handling and maintenance, which you have to build yourself.
MuleSoft Anypoint. A strong platform that combines integration and API management, with an API-led approach and a developer-oriented toolset. Popular in large enterprises and usually positioned at the premium end of the market.
Workato. An integration and automation platform with a recipe-based, business-friendly approach and a large library of connectors. Often chosen when business and IT teams build automations together.
Zapier and Make. Easy, affordable tools for simple automations between SaaS applications, such as “new form entry creates a CRM contact”. Great for small cases. They are usually not designed for high volumes, on-premises ERPs or complex error handling.

If you already use one of these platforms for something else, start your evaluation there. And whichever you choose, the patterns in this guide matter more than the product.

Where to go next

Two practical articles show the most important patterns of this guide, built step by step in Boomi:

Syncing e-shop orders to your ERP with Boomi: incremental polling with a watermark, and how to avoid duplicate orders on retry.
Error handling and retries in Boomi integrations: transient vs permanent errors, retries with backoff, manual review and alerts.

For the design decisions behind them, see also our guide to integration patterns every team should know.