A typical company runs many software systems: a CRM, an ERP, a website, an online store, a marketing platform, a support desk, a payroll service. Each is good at its job. The trouble starts in the gaps between them. Integration is the work of making separate systems share information accurately, and it is where many business systems projects succeed or fail.
This is the second step in our business systems learning path. Start with CRM and ERP Explained if you have not read it.
Why systems need to talk
Without integration, people move information by hand: exporting a spreadsheet from one system, retyping orders into another, emailing updates across departments. That is slow, it introduces typing errors, and it means each system is a little out of date. Integration replaces those manual handoffs with automatic, repeatable ones.
APIs: how programs ask each other for things
Most modern integration uses APIs, short for application programming interfaces. An API is a published set of requests a system will accept from other programs, and the responses it will send back.
A restaurant is a useful comparison. You do not walk into the kitchen; you order from a menu through a server. The menu lists what is available and how to ask for it. The kitchen prepares it and the server brings it back. An API is the menu and the server: it defines exactly what another program can request ("give me customer 4417", "create this order") and how the answer will be returned.
APIs also enforce rules. They check that the requesting program is authorized, that the request is well formed, and that it is allowed to see or change the data involved.
Ways to move data
Integrations differ in when and how data moves:
- Real-time. One system notifies another the moment something happens. When a deal is won in the CRM, the ERP creates the order immediately. Good for anything customers or staff are waiting on.
- Batch. Data is collected and moved on a schedule, such as every hour or every night. Simpler and efficient for large volumes that do not need to be instant, like daily sales totals.
- Event-driven. Systems publish events ("order shipped") that any interested system can react to, without the sender needing to know who is listening.
- Middleware. A dedicated integration platform sits between systems, translating and routing data, so each system connects to one hub instead of to every other system.
The single most important decision: the system of record
Suppose a customer's address exists in the CRM, the ERP, and the online store. The customer updates it in the store. Which version is correct? If nobody has decided, the answer depends on which system you look at, and the package goes to the old address.
The fix is to name a system of record for each kind of data: the one system whose version is authoritative. Other systems receive copies and do not overwrite it. For example:
| Data | System of record | Others receive a copy |
|---|---|---|
| Customer contact details | CRM | ERP, store, support desk |
| Product prices and stock | ERP | Store, CRM |
| Invoices and payments | ERP | CRM, so service teams can see them |
| Support cases | Support desk | CRM |
With these decisions written down, every integration has a clear direction, and disagreements have a clear answer.
What goes wrong
Common integration failures include:
- Mismatched definitions. Sales counts a "customer" when a deal is signed; finance counts one when the first invoice is paid. Both systems are right, and their reports never match.
- Duplicates. The same company appears three times with slightly different names, so its history is split.
- Mapping errors. A field in one system does not mean quite the same thing in another, such as a "state" field that holds a region in one and a sales stage in the other.
- Silent failures. A sync stops working, nobody is alerted, and the systems drift apart for weeks.
- Timing. Two systems update the same record at nearly the same moment and one change overwrites the other.
How integrations are tested
Integration testing checks the connections, not just each system on its own:
- Each direction, each kind of record. Create, update, and delete in the source; confirm the right result in the target.
- Boundaries and bad data. Very long names, missing fields, unusual characters, and records that violate the target system's rules.
- Failure and recovery. What happens when the target system is down? Are changes queued and retried, and is someone alerted?
- Volume. Does the nightly batch still finish when the business is ten times larger?
- Reconciliation. Totals and record counts in both systems agree after the sync.
These are ordinary testing techniques, such as boundary values, risk-based priorities, and clear expected results, applied to the spaces between systems.
Try it yourself
Pick two apps you use that share information, such as a calendar and a video-meeting app, or a fitness tracker and a health app. Answer:
- What information passes between them, and in which direction?
- Does it move in real time or on a schedule?
- If you change the same item in both apps, which one wins? Is that the system of record?
- Design three tests that would show whether the connection works correctly, including one for when something goes wrong.
The next level of this path moves to the organizational view: how revenue teams agree on one trusted number, and how mature teams test integrations across a whole business.
Look up any unfamiliar term in our glossary.