Integration and connected systems
The order is in one system.
The warehouse is in another.
Your systems do not all need to be replaced. They do need to work together. We connect Dynamics with the operational, warehouse, ecommerce, CRM and specialist platforms your business still needs, with clear ownership when something goes wrong.
Sometimes the right answer is fewer interfaces, not another one.
Sound familiar?
Your applications do not need to become one system. Your process does need to behave like one.
Nobody rings up to complain about an interface. They ring because the order did not arrive, the stock was wrong or the invoice never went out.
Most integration conversations start with one of these, and none of them are really technology problems.
The order is in one system and not the other
Somebody notices at the end of the week, usually because a customer rang.
Somebody rekeys it every morning
A spreadsheet and an hour of somebody's day are holding two systems together.
Two systems disagree about stock
The website says available, the warehouse says otherwise, and the customer finds out first.
It failed quietly
No alert, no error anyone saw, and no way of knowing how long it had been happening.
Integration in practice
Three different problems. Three different architectures.
Integration is rarely about connecting two pieces of software. It is about keeping a business process intact when responsibility passes between systems. The technology followed the requirement in each of these.
Hill & Smith Infrastructure
Connecting field activity straight to finance
What happened on site lived in Reflow. What finance could invoice lived in Dynamics. Somebody had to move it.
Connected Reflow to Dynamics 365 Finance and Operations using InteliSense IDM, so operational activity arrives in finance as transactions rather than as a rekeying task.
Field activity reaches the finance system without a manual handover, and failures surface as exceptions instead of being discovered later.
- Integration
- IDM
- Field operations
- FSCM
Eland Cables
Connecting an external warehouse without losing ERP control
Warehouse execution runs in ATMS, a specialist external system, while stock and financial control belong in Dynamics 365.
Integrated Dynamics 365 Finance and Operations with the ATMS warehouse management system on Azure, using the Dynamics data management framework for structured, recoverable message exchange.
Warehouse operations keep the system built for them, and Dynamics remains the record for stock and finance rather than a downstream copy.
- Integration
- Azure
- Warehouse
- FSCM
Canon Collins Trust
One reliable list of people, held in the right place
Contact information lived in spreadsheets and SharePoint alongside CRM, so nobody could say which version was current.
Used Power Automate to keep the master list flowing between SharePoint, Excel and CRM, so the working files people already use stay aligned with the CRM record.
The team keeps working the way it prefers while CRM stays current, without a manual import routine.
- Power Automate
- SharePoint
- CRM
- Automation
Where this usually applies
The connections we see most often.
Connecting two APIs is rarely the difficult part. The harder questions are what should move, which system owns it and what the business expects to happen next.
Ecommerce and ERP
Orders, customers, prices and availability moving between a website and the finance system.
Warehouse and 3PL
Orders out, confirmations and stock back, with the awkward exceptions thought about first.
EDI and trading partners
Structured documents where the customer sets the format and the timetable, not you.
CRM and ERP
Where the argument about who owns the customer record has to be settled before anything is built.
Finance, payroll and expenses
Periodic, controlled, and unforgiving if the posting does not reconcile.
Specialist operational systems
Field, production or industry systems that stay because they are the right tool for the job.
We are not limited to this list. The first question is whether the system provides a supported way to exchange the information the process needs.
InteliSense IDM
IDM: when the integration pattern is worth reusing.
We built IDM after meeting the same integration problem repeatedly: different systems, different data structures and the same need for controlled mapping, movement, validation and traceability.
Connect
Supported systems and APIs. We check what your specific product genuinely offers rather than assume a connector exists.
Map
Translate one system's structure into the shape the other expects, agreed with the people who own the records.
Control
Validate before posting, hold failures as exceptions and retry without creating a second order or invoice.
Trace
A record of what moved and what happened to it, so a question about yesterday has an answer.
Not every system belongs on IDM.
IDM does not make an unsupported API supported, and it does not remove architecture, security or failure design. We use it where its reusable capability genuinely reduces unnecessary development. Eland Cables did not need it. Azure integration services and the standard Dynamics data management framework were the better answer there.
Before we connect anything
Five questions before we connect anything.
They take a conversation rather than a workshop series, and they are the difference between an interface that settles down and one that never quite does.
Real time is a business requirement, not an architecture trophy.
When something goes wrong
Monitor the process. Not just the pipe.
An API returning success only proves one step succeeded. The business needs confidence that the whole process finished.
- Order received: The website, trading partner or field system says a job exists.
- ERP created: Dynamics accepts it and the commercial record starts.
- Warehouse released: The system doing the physical work picks it up.
- Dispatched: Goods leave, and the transaction has to reflect that.
- Customer updated: The only step the customer actually judges you on.
Fail visibly
A failure nobody sees is worse than one that stops the process. Exceptions surface with the original payload retained.
Retry safely
Bounded retries and replay designed so a correction cannot create a second order or a second invoice.
Reconcile the outcome
For flows that matter, the systems are compared so a gap is found before a customer finds it.
When you didn't build it
Inherited an integration nobody owns?
We regularly meet interfaces from previous partners, acquisitions and internal development. The first job is to understand why they exist, what depends on them and whether they should still be there.
Keep
It works, it is understood, and it is worth leaving alone.
Fix
The purpose is sound. The failure behaviour, security or documentation is not.
Replace
A supported pattern now does the job the custom code was written for.
Retire
Nothing downstream depends on it any more, and nobody had noticed.
Check your integration position
A few questions before integration scope is agreed.
A routing aid rather than a quote. Your answers come with you into the conversation, so nothing has to be repeated.
Question 1 of 6
0 of 6 answered
Common questions
Questions leaders ask about integration.
Start with the broken handover
What isn't connecting today?
It might be a warehouse, website, CRM, field system or a process someone still holds together in Excel. Show us where the handover breaks and we'll help work out whether the right answer is integration, automation, consolidation or something simpler.