Integration & Connected Systems
Your business process
does not stop where
one application ends.
FragmentationFlow
A customer journey may begin in CRM and finish in Finance. An ecommerce order may pass through inventory, warehouse, carrier and payment systems. A manufacturing process may depend on ERP, planning, machines, suppliers and data. The applications do not need to become one system. But the business process needs to work across them.
Connect what the process needs. Keep ownership clear. Make failure visible.
Integration is not about making systems talk. It is about making the business process continue.
An API returning 200 does not necessarily mean the customer order completed. Good design considers what initiated the process, which system owns the information, what must happen next, what happens if it fails, who knows, and how the business state is reconciled.
In short
What this page decides.
- An integration exists because a business process crosses systems. That is the only justification worth building on.
- Decide whether both systems should remain before connecting them. Integrate only what the future operating model still needs.
- Decide which system is the authoritative source, then move only what the process genuinely needs.
- Choose the pattern from business timing and consequence, not from architectural preference.
- Design failure, reconciliation and traceability before go-live, not after the first incident.
- Prove the business outcome, then agree who operates it, what it costs to own, how it changes and when it should end.
Before the API
Map the business event before designing the connection.
The integration exists to protect a flow that somebody in the business already depends on.
Business event
Customer places an order.
Process
The order is validated.
System owner
ERP creates the order.
Data required
Inventory is allocated.
Integration
The warehouse is asked to fulfil.
Business result
Shipment is confirmed.
Confirmation
The customer is informed.
Before designing an interface
Integration should not be selected simply because two systems exist.
Ask what should happen to the dependency itself first. This matters most during Transform and Recovery, when the landscape is still being decided.
Retain and integrate
The system earns its place in the future operating model and the process genuinely needs the connection.
Replace
The capability should move to another platform, so an interface would only extend the life of a decision already made.
Consolidate
Several systems or interfaces are doing overlapping work and the simplification is worth more than the connection.
Retire
The dependency exists because of history rather than a current business requirement.
Defer
The process may need it later, but not enough is settled yet to design the interface responsibly.
Integrate only what the future operating model still needs.
Authority
Decide authority before copying data.
If two systems both believe they own the same information, integration becomes conflict management. Ownership is an architecture decision, not a product rule.
Authoritative operational source
Where the operational truth is created and controlled. Changes made here are the ones the business treats as real.
Reference or consuming system
Where selected context is required so another process can continue. It holds a copy for a purpose, not the authority.
Analytical representation
Where information may be copied, transformed and combined historically for analysis. Holding history does not make a platform authoritative for the source transaction.
Analytical history may be held in the analytical or data platform, while the originating business application remains authoritative for the source transaction. Holding the longest history does not make a platform the place where the transaction is created and controlled.
- Customer
- Supplier
- Product
- Price
- Inventory
- Order
- Shipment
- Invoice
- Payment
- Case
- Project
- Document
- Customer
- Supplier
- Product and item
- Price
- Employee
- Location
- Project
- Asset
- Chart of accounts and dimensions
Integration does not mean replicating the whole database. Systems should receive the information the process needs, at the time it is needed, at the level of detail it requires.
The landscape
A connected business does not require one application to do everything.
Keep specialist capability where it creates value. Connect it where the process requires it.
- ERP
- CRM
- Ecommerce
- PIM
- WMS
- TMS
- Payroll
- Banking
- Payment
- Document management
- Public-sector systems
- Clinical and care systems
- Supplier platforms
- Data platforms
- Microsoft 365
ERP and CRM
Connect the customer promise to operational reality: customer, opportunity and quote context flowing into order, inventory, delivery, invoice and payment, with useful status returning the other way.
- Customer
- Opportunity
- Order
- Inventory
- Delivery
- Invoice status
- Account position
Business Central
Common connection points for a mid-market landscape. Not every one of these is a standard connector, and we will say which is which.
- CRM
- Ecommerce
- PIM
- Warehouse
- Banking
- Payment
- Payroll
- Expenses
- Data
- Power Platform
- Carrier
- Specialist applications
Finance & Supply Chain
Enterprise operations usually connect further out, into execution systems, planning and external logistics.
- CRM
- Warehouse automation
- Manufacturing systems
- Planning
- Transport
- PIM
- Ecommerce
- Banking
- Data
- Suppliers
- External logistics
Across the boundary
One order, several systems, one promise to keep.
The website should not promise stock the operation cannot fulfil, and the warehouse should not learn about an order by telephone.
Ecommerce
The customer places the order online.
Customer and account
The right account, not a duplicate.
Order
Priced, validated and accepted.
ERP
The transaction becomes operational reality.
Inventory
Allocated against what actually exists.
Warehouse
Picked, packed and dispatched.
Shipment and status
Tracked, and returned to the channel.
Customer
Told what is happening, without being chased.
- PIM may own marketing description, attributes, images, digital content and channel information
- ERP may own item, cost, inventory, supply and financial treatment
- Define the boundary deliberately rather than discovering it during go-live
- The website should not promise stock the operation cannot fulfil
Integration patterns
Different problems justify different connections.
No pattern is universally better than another. The process decides.
API
Use where a request or an action requires a direct response before the process can continue.
Event
Notify other systems that something happened.
Queue or message
Buffer work reliably so it is processed asynchronously without losing it.
Batch
Move information periodically where delay is acceptable.
File
Exchange structured information where the partner or process requires it.
Connector or ISV
Use supported packaged capability where it genuinely fits the process.
Real time is a business requirement, not an architecture trophy. Move data fast enough for the decision or the process, not as fast as technically possible.
- How quickly does the information change?
- How quickly can somebody act on it?
- What happens if it is delayed?
- What does real-time integration cost to operate?
- Payment authorisation may need an immediate response. Management reporting usually does not.
- A product catalogue may tolerate delay. Warehouse availability often needs far greater freshness.
When the connection breaks
Integration design is incomplete until failure has been designed too.
Most integration pain is not the connection that was never built. It is the connection nobody planned to fail.
- System unavailable
- Timeout
- Invalid data
- Authentication failure
- Duplicate
- Business-rule rejection
- Partial transaction
- Rate limit
- Unexpected response
Requested is not the same as completed.
Request sent
The process asked for something.
System responded
A response is not an outcome.
Business record created
Order, invoice, payment, shipment or case.
Expected state confirmed
The record says what it should say.
Reconciled
The business outcome is proven, not assumed.
Important flows, such as order creation, invoice posting, payment recording, shipment confirmation and case opening, need a way to prove the business outcome rather than assume it.
Monitoring and traceability
Problems should surface early enough for someone to act.
Monitoring only becomes useful when it leads to ownership, triage and action. For business-critical integrations it should expose problems early enough for the agreed support model to respond.
- Failures and success rate
- Queue backlog and dead-letter backlog
- Latency and stale or blocked processing
- Volume anomaly
- Authentication and dependency availability
- Data rejection and missing response
- Repeated retry
- Deployed version
- Business outcome reconciliation
- A dashboard nobody owns is not monitoring
Responsibilities
An integration can cross application boundaries. Accountability still needs boundaries.
Not every organisation uses these titles, and some people hold several of these roles. The responsibilities still need a name against them.
Business process owner
Owns the end-to-end business process and the outcome the integration is there to protect.
Source application owner
Owns the source capability and the data it creates.
Target application owner
Owns how the received information is processed.
Data owner
Owns the meaning, quality and mapping decisions behind the information being moved.
Integration owner
Owns the design and operation of the interface itself.
Security owner
Owns identity, permissions and data-access decisions across the boundary.
Support owner
Owns operational triage when something does not complete.
Third parties
Own the products and services they are contracted to provide.
Technical qualification
The detail behind the decisions, for those who need it.
Reliability requirements should follow business consequence. Everything below is proportionate to what happens if the process fails, not applied uniformly.
Connected does not mean open
Security and ownership continue across the boundary.
An integration inherits the responsibility of both systems it touches.
- Identity, authentication and authorisation
- Least privilege
- Service identities
- Credential lifecycle
- Data scope
- Encryption, logging and audit
- Environment separation
AI may need context from several systems. That does not mean it should receive unrestricted access to all of them.
User or process
A real request, with a real purpose.
AI or agent
Interpretation, not unrestricted authority.
Approved tool
A defined action, with defined inputs.
Integration
The controlled route into the system.
Business system
The action lands under a known identity, and is audited.
- Read customer
- Check stock
- Read order
- Create task
- Draft email
- Prepare purchase request
- Find invoice
- Update approved status
Each action should have a purpose, a permission, defined inputs, validation, a result and an audit trail.
Two different jobs
Operational integration and analytical integration solve different problems.
Getting this boundary wrong is one of the quieter causes of fragile architecture.
- Operational: something must happen in another system
- Analytical: information needs to be combined for analysis
- Creating an ERP order is operational. Combining ERP and CRM revenue history is analytical.
- Do not use operational APIs as an accidental data warehouse
Delivery discipline
Build it because the process needs it, then look after it.
Happy-path integration testing proves only the happy path.
- Does a supported standard connection exist, and does it actually fit?
- If not, is a supported ISV or connector the better answer?
- If not, custom integration may be justified
- Evaluate business value, complexity, ownership, support, upgrade, security, volume and failure
- Custom integration should exist because the process needs it, not because building interfaces is interesting
Transition
Integration often has to support the journey before it supports the future.
Temporary architecture should have an exit plan, agreed before it is built.
- Legacy ERP alongside new ERP
- Old CRM alongside new CRM
- Data migration and interim interfaces
- Parallel operations
- Temporary architecture should have an exit plan
Confidence gates
Four points where the connection has to justify itself again.
These are decision controls rather than project bureaucracy. Each one is a place where the honest answer may be to stop, simplify or defer.
Gate 1
Before design
Business fit
The first gate asks whether the connection should exist at all. It is the cheapest place to stop.
Confirmed at this gate
- The business event and the outcome it produces
- Which systems genuinely need to remain in the future operating model
- Which system is the authoritative source
- The value the integration creates
- The alternatives, including doing nothing
Decision
Integrate · Replace · Consolidate · Retire · Defer · Redesign the process
Gate 2
Before build
Architecture and responsibility
The second gate settles how the connection works and who owns each part of it, before anything is built.
Confirmed at this gate
- Source, destination, data and mapping
- Pattern, timing and expected volume
- Security and identity
- Failure behaviour and reconciliation
- Support ownership and third-party dependencies
- The commercial implications of owning it
Decision
Proceed · Simplify · Re-scope
Gate 3
Before production
Prove
The third gate tests according to risk, including the paths people prefer not to think about.
Confirmed at this gate
- Happy path, invalid data and duplicate handling
- Timeout, unavailable system and rate limit
- Business-rule rejection and partial failure
- Retry, replay and volume
- Security
- Reconciliation and the end-to-end business outcome
Decision
Production candidate · Remediate · Repeat
Gate 4
At cutover
Production
The final gate is a go or no-go decision made with the operational picture visible, not an administrative sign-off.
Confirmed at this gate
- Production endpoints, credentials and deployment
- Cutover plan and sequencing
- Monitoring, alerting and named ownership
- Runbook and support route
- Reconciliation, fallback and rollback
- Residual risks, accepted openly
Decision
Go · No-go · Controlled deferral
Integration lifecycle
An integration is an operating capability, not a one-off interface build.
Interfaces can be changed, consolidated, replaced, suspended and retired. Retirement is a valid and often overdue outcome.
Discover
What process crosses systems, and why.
Qualify
Should this dependency exist at all?
Design
Authority, data, pattern, failure and security.
Build or configure
Standard capability first, custom where justified.
Prove
Tested against consequence, not only the happy path.
Cutover
A business-state transition, sequenced and reconciled.
Operate
Owned, supported and documented.
Monitor
Visible failures and traceable transactions.
Improve
Simplified, consolidated or made more reliable.
Retire
Ended deliberately when the process no longer needs it.
Cost of ownership
A technically successful integration still has to be commercially sensible.
The build is usually the smallest part of the cost. What follows it rarely is.
- Development or configuration effort
- Middleware or platform licensing, where any is used
- Connectors and ISV products
- API or transaction consumption
- Data movement
- Third-party service costs
- Environments
- Monitoring and support
- Regression testing and upgrades
- Administration and vendor dependency
Integration recovery
A connected systems health assessment, before anything is rebuilt.
Where an estate has grown faster than its ownership, the first job is establishing what exists and why. Rebuilding an interface nobody has decided to keep is the most expensive answer available.
- Interfaces, connectors, files and APIs
- Middleware, scheduled jobs and scripts
- Temporary processes that quietly became permanent
How this connects
Integration shows up in recovery, transformation and improvement.
It is rarely the headline of a programme. It is often what determines whether the programme works.
Recover
Unknown interfaces, no monitoring, duplicate transactions, unowned mappings, expired credentials and manual reprocessing are common recovery findings.
Transform
Which systems remain, which retire, which own data, and which temporary interfaces disappear?
RAPID
Many bespoke interfaces, unclear ownership and complex third parties may not fit an accelerated route.
Optimise
Fewer interfaces, better monitoring, less duplication and stronger reconciliation, without a new programme.
What the evidence proves
We separate delivery evidence from integration evidence.
Our published customer stories are genuine accounts of delivery. They are not, on their own, verified proof of integration performance, and we will not present them as though they were.
Level 1: Customer delivery evidence
A verified customer account of work InteliSense delivered.
Published customer stories exist. They describe delivery, not integration performance.
Level 2: Integration demonstration
A representative end-to-end flow shown in a controlled environment.
Available on request
Level 3: Production integration
A verified operating integration, with owners, monitoring and support.
No published example yet
Level 4: Verified outcome
A measured improvement or risk reduction against a baseline captured before the change.
No published example yet
Check the fit
Six questions before an interface is designed.
This is a routing aid rather than an architecture decision. Your answers are carried into the conversation, so nothing has to be repeated.
Indicative signal
Answer the questions and we will show a likely starting point. This is a recommended next route rather than an architecture decision, and sometimes the honest answer is that the connection should not be built at all. Please keep every answer at organisational level: no customer, personal or case information.
Your answers are carried through, so you will not be asked to repeat them. Final qualification is always a conversation.
Common questions
Questions leaders ask about connected systems.
Connected systems
Where does the process break when one system hands work to another?
If important processes depend on ERP, CRM, ecommerce, warehouse, specialist applications or third parties working together, we can help establish the right boundaries, ownership and integration approach.