Every shared record carries the IDs of its counterparts in other systems, so updates match exactly instead of by name.
MechanismA cross-reference table or external ID fields on each system.
Software & systems integration
Systems integration services for applications that share one process
Your CRM, ERP, billing, support and e-commerce systems each hold part of the truth. We map which system owns which data, choose the integration pattern, orchestrate the processes that cross them, and keep the whole thing observable. Business software only: no hardware, no cabling.
Integration layerEvents, routing, mappingMiddleware, iPaaS or a broker
Each system connects once, to the integration layer:
- CRMexchanges data both ways withIntegration layerCustomers, deals · Events, routing, mapping
- ERPexchanges data both ways withIntegration layerOrders, stock · Events, routing, mapping
- Billingexchanges data both ways withIntegration layerInvoices, payments · Events, routing, mapping
- Supportexchanges data both ways withIntegration layerTickets, SLAs · Events, routing, mapping
- E-commercesends data toIntegration layerWeb orders · Events, routing, mapping
- Marketingexchanges data both ways withIntegration layerCampaigns, consent · Events, routing, mapping
- Integration layersends data toWarehouseEvents, routing, mapping · Reporting and BI
- Fulfilmentexchanges data both ways withIntegration layerPicking, shipping · Events, routing, mapping
- Event-driven
- Scheduled
What systems integration means here
Systems integration is the work of making separate business applications behave as one system for the processes that cross them. For software, it means deciding which application owns each kind of data, choosing how applications exchange it (directly, through middleware, or through events), building the connections, and orchestrating multi-step workflows such as order-to-cash. Software integration and application integration describe the same work at smaller scale.
Who owns which data
The first deliverable of any systems integration project. Without it, two systems end up editing the same customer address.
| Data domain | CRM | ERP | Billing | Support | Marketing | E-commerce | Warehouse |
|---|---|---|---|---|---|---|---|
| Customer accountName, addresses, tax ID | SoTsource of truth | Copyread copy | Copyread copy | Copyread copy | Copyread copy | Copyread copy | Copyread copy |
| Credit limit and terms | Copyread copy | SoTsource of truth | Copyread copy | not stored | not stored | not stored | Copyread copy |
| Contact consentMarketing permissions | Copyread copy | not stored | not stored | not stored | SoTsource of truth | Copyread copy | Copyread copy |
| Products and prices | Copyread copy | SoTsource of truth | Copyread copy | not stored | not stored | Copyread copy | Copyread copy |
| Sales orders | Writes backwrites back selected fields | SoTsource of truth | Copyread copy | Copyread copy | not stored | Writes backwrites back selected fields | Copyread copy |
| Invoices and payments | Copyread copy | Copyread copy | SoTsource of truth | not stored | not stored | not stored | Copyread copy |
| Support tickets | Copyread copy | not stored | not stored | SoTsource of truth | not stored | not stored | Copyread copy |
“Writes back” means a system may create or update a record in a domain it doesn’t own, through an agreed path. Here the CRM and the store create sales orders, but the ERP is the order’s source of truth from that point on. If that ERP is itself being built or replaced, see ourERP development work.
Integration patterns
Four ways to connect applications. Most landscapes use more than one.
| Pattern | How it works | Fits when | Trade-off |
|---|---|---|---|
| Point-to-point | Each pair of systems is connected directly through their APIs. | Two to four systems with few, stable flows. | Connections multiply with each new system; monitoring is scattered. |
| Hub-and-spoke (middleware, iPaaS) | Each system connects once to a central layer that maps and routes data. | Many systems sharing the same data; a team to own the platform. | Platform licence and a central dependency to run well. |
| Event-driven (publish/subscribe) | Systems publish events such as order.created to a broker; interested systems subscribe. | Several consumers per event, near-real-time needs, systems that change independently. | Eventual consistency; needs idempotent consumers and good event design. |
| Batch and file | Scheduled extracts or files moved between systems. | Reporting, large volumes, partners or legacy systems without APIs. | Hours of delay; failures surface late without reconciliation. |
A cross-system workflow: order to cash
Four systems, one process. The integration has to sequence the steps and know what to do when one fails.
- Triggerquote.acceptedCustomer signs the quote
eventPublished to the integration layerQuote
- CRMDeal marked Closed WonAccount and line items final
eventOrder requestedQuote -> SalesOrder
- ERPSales order created, stock reservedERP becomes the order’s source of truth
- Out of stockCRM taskOwner asked to agree a new dateDeal stays won; order waits
eventOrder releasedorder.created
- Out of stock
- FulfilmentPicked, packed, shippedTracking number generated
eventShipment confirmedshipment.sent
- BillingInvoice issuedTerms from the ERP account
- Invoice rejectedCompensateOrder flagged, finance alertedNo silent gap between shipped and billed
scheduledPayment matched by the bank feedinvoice.paid
- Invoice rejected
- CRMDeal shows paid and shippedRenewal and support see the full history
- Event-driven
- Scheduled
- Failure path
Keeping data consistent
Integrated systems are never perfectly in step. These are the mechanisms that keep the differences small and visible.
Global identifiers
Idempotent writes
Sending the same update twice has the same effect as sending it once, which makes retries safe.
MechanismIdempotency keys or upserts keyed by external ID.
Eventual consistency
After a change, other systems catch up within seconds or minutes. Processes are designed for that delay rather than pretending it doesn’t exist.
MechanismAgreed delay per flow, and screens that show “pending sync” where it matters.
Reconciliation jobs
Scheduled comparisons of counts and key fields between systems catch records that slipped through.
MechanismDaily report of differences, routed to the data owner.
Ordering and duplicates
Events can arrive twice or out of order. Consumers check versions and timestamps before applying a change.
MechanismVersion numbers or last-modified checks on every update.
Legacy and custom software
Integration landscapes rarely consist only of modern SaaS. We work with what you have.
- SOAP
SOAP and XML services
Common in older ERP and finance systems. We consume them as they are and translate at the boundary.
- Database
Direct database integration
Read from replicas or change logs when there is no API, agreed with the system owner. We avoid writing to another application’s database behind its back.
- Files
File drops and EDI-style exchanges
Scheduled files with validation, counts and archiving, so a partial file never loads silently.
- Wrap
An API around the legacy system
A small service that exposes the legacy system through a clean, documented API, so the rest of the landscape is insulated from it and it can be replaced later.
- Last resort
Screen-level automation
Robotic automation of a user interface only when nothing else is available, with extra monitoring because screens change without notice.
The integration assessment
Where most systems integration projects should start. Fixed scope, usable on its own.
Inventory
List the applications, their APIs and limits, existing integrations and manual handoffs, with volumes.
DeliverableSystem and flow inventory
Ownership map
Decide the source of truth for each data domain with the people who own the processes.
DeliverableData ownership map
Target architecture
Choose the pattern for each group of flows, the middleware if any, and how monitoring works.
DeliverableTarget integration architecture
Roadmap
Sequence the work so each step removes a manual handoff and stands on its own.
DeliverablePhased roadmap with effort ranges
Operating the integration layer
One place to see every flow across every system.
integration-layer · order-to-cashillustrative
- 11:20:04okcrm -> erp · orderquote.accepted Q-7781 -> SO-3302 created, stock reserved
- 11:58:40okwms -> layer · shipmentshipment.sent for SO-3302 delivered to billing and CRM
- 12:01:15retrylayer -> billing · invoiceBilling API timeout, retry 1 of 5 scheduled
- 12:01:47oklayer -> billing · invoiceINV-2290 issued on retry, idempotency key reused
- 02:00:00failedreconcile · orders2 shipped orders without invoice, report sent to finance
- 02:30:00queuedlayer -> warehouseNightly load queued
- End-to-end tracing. One correlation ID follows a quote from the CRM to the paid invoice.
- Reconciliation, not hope. Nightly checks compare systems and report differences to the data owner.
- Change control. Releases of any connected system are tested against the flows that depend on it.
- Clear ownership. Each flow has a named owner and a runbook entry, whether that’s your team or ours.
Which integration page fits?
Systems integration covers the landscape. These pages go deeper on parts of it.
- Ifthe work is one connector between two applications, with its auth, limits and error handlingAPI integration The five stages of an API integration and the engineering checklist./integrations/api-integration/
- Ifthe CRM is the centre and the main question is customer data ownership and syncCRM integration Sync modes, conflict rules, mapping and CRM platform APIs./crm/crm-integration/
- Ifpart of the landscape is being replaced and data must move to the new systemCRM migration Mapping, trial loads, reconciliation and cutover./crm/crm-migration/
- Ifyour landscape includes a CRM and you want the full range of CRM and integration services.CRM & integrations Overview of every CRM and integration service./crm/
Questions about systems integration
What are the four types of system integration?
Commonly described as: point-to-point (each pair of systems connected directly), hub-and-spoke (systems connect to a central middleware or iPaaS that routes and transforms data), event-driven (systems publish events to a broker and others subscribe), and batch or file-based (data exchanged in scheduled extracts). Older literature also names the enterprise service bus as a variant of the hub model. Most real landscapes mix two or three of these.
What does a systems integration company do?
For business software, a systems integration company works out how applications should share data and process, then builds and runs the connections: ownership of each data domain, the integration pattern, the connectors, orchestration of workflows that cross systems, and the monitoring that keeps them working. Comtau does this for business applications such as CRM, ERP, billing, support and e-commerce; we don’t install hardware or networks.
Do we need middleware or an iPaaS?
Not always. With two or three systems and a few flows, direct integrations are simpler to run. Once several systems need the same data, or one process touches four applications, a central layer (an iPaaS, a message broker or a small integration service) reduces the number of connections and gives one place to monitor them. We recommend based on the number of systems, flows and the team that will own it.
Can you integrate our custom or legacy software?
Yes. If it has an API, we use it. If it has SOAP services, a database or file exports, we can work with those, and often wrap the legacy system in a small modern API so the rest of the landscape doesn’t depend on its quirks. See API integration for connector-level detail.
What does “turnkey integration” mean here?
We take responsibility from assessment to a running, monitored integration: design, build, testing, data backfill, go-live and handover with documentation. You still make the business decisions, such as which system owns customer data; we make sure those decisions are written down and implemented.
How do you handle failures between systems?
Every flow has a defined failure path. Retries are safe because writes are idempotent; records that can’t be processed go to a review queue with the reason; long workflows use compensating steps, such as cancelling an order if invoicing fails permanently. Reconciliation jobs compare systems on a schedule to catch anything that slipped through.
Next step
Map the landscape with us
Tell us which applications are involved and which process suffers most from manual handoffs. An integration assessment turns that into an ownership map and a roadmap.
Request an integration assessmentUseful to have ready
- The applications involved, including spreadsheets and legacy tools
- The cross-system process that hurts most (for example, order to cash)
- Existing integrations or middleware, and who runs them
- Volumes, and any compliance or data residency constraints
Not everything is needed. A rough answer is enough to start.