Microsoft Business Applications ecosystem
ProductsOperating model
Finance may sit in ERP. Customer relationships may sit in CRM. Workflows may use Power Platform, reporting may use Power BI, enterprise data may extend into Fabric and AI may work across several of them. The question is not how many Microsoft products you own, but which capabilities the operating model actually needs and how they hold together.
Identity, security, governance, integration, adoption and licensing apply across every layer, not just the newest one.
Illustrative. No organisation needs every layer, and the right mix depends on the operating model.
Microsoft gives you a platform. It does not automatically give you an operating model.
The organisation still needs to decide which application owns each process, which system owns each piece of data, where integration is justified, where standardisation matters, where extension adds value, and where AI should and should not act.
In short
Before the technology
Technology architecture should follow the operating model, not define it by accident.
What the organisation is actually trying to change.
How the work needs to move between people and teams.
What each step creates, needs and owns.
What someone has to decide, and with what evidence.
Which application is the right home for that process.
Where systems genuinely need to exchange information.
Where rules are known well enough to remove manual effort.
How performance is explained rather than reconstructed.
Where interpretation or prediction adds something reporting cannot.
The Microsoft business platform
Open only what is relevant. Each area explains its purpose in the operating model rather than the product feature list. No organisation needs all six.
Run the operation
InteliSense delivers two Microsoft ERP routes. Choose by how complex the operation actually is, not by turnover.
Relatively controlled complexity
A broad connected ERP core where operational and governance complexity remains manageable.
Deeper enterprise complexity
Enterprise capability where entity, supply chain, manufacturing or control complexity is greater.
Decision factors
Choose by operating complexity. Not turnover alone.
Manage relationships and service
CRM connects the organisation to the people and organisations it serves. ERP records what was ordered, delivered, billed and paid. They should connect where the process crosses them.
CRM
ERP
ERP and CRM do not need the same data. They need the right data.
Data ownership
One system should hold the authoritative operational record. Other systems may hold a governed representation of it for reporting, insight or AI. Confusing the two is where trust in data usually breaks.
Customer relationship
CRM usually holds the authoritative record of the relationship.
Operational authority
Financial transaction
ERP should hold the authoritative financial record.
Operational authority
Inventory and fulfilment
ERP or the supply chain platform holds the operational position.
Operational authority
Analytical history
The data layer, such as Fabric, holds a governed representation for analysis.
Analytical representation
Reporting consumers
Power BI reads the governed model rather than becoming a second source of truth.
Consumer
Documents and knowledge
SharePoint may be the appropriate home, referenced from the application.
Operational authority
Identity and access
Microsoft Entra ID governs who can see and do what across the estate.
Control plane
Different platforms may need reference, context, status, selected attributes or transaction events. They do not necessarily need complete replicated datasets. That discipline matters most across ERP and CRM, data platforms, AI, public-sector information and health and care data.
Extend the platform
Power Apps for focused applications, Power Automate for workflow, Dataverse for structured application data and Power Pages for external experiences where appropriate.
Low code should reduce complexity. Not make application creation uncontrolled.
Copilot Studio sits here too, where a conversational or agent experience needs the same ownership, security and lifecycle discipline as any other application.
Understand what is happening
Reporting and analytics serve different questions. The right architecture depends on which question the organisation needs answered.
What needs attention now?
What is changing?
Why is it changing?
What may happen next?
Microsoft Fabric may be appropriate when the business needs cross-system analytics, larger data volumes, historical modelling, shared governed data, advanced analytics or foundations for AI. The analytical model may need to be broader than any individual business application.
Not every Power BI requirement needs Fabric. Simpler requirements may be addressed through application reporting, Power BI, Dataverse or direct ERP and CRM data models. Fabric should solve a data architecture problem, not simply exist because it is available.
From data to decision
Start with the business decision. Then decide whether reporting, automation, AI or prediction is the appropriate intervention.
Foundation: bring the operational information together.
Foundation: agree definitions, ownership and quality.
Foundation: explain what is happening and why.
Decide which intervention the decision actually needs.
Show it works on real data before it is relied upon.
Run it with identity, audit, review and reconciliation.
Confirm the decision improved, or stop.
Automation
Use when the rules are already known.
If an invoice is over £50k, request approval.
AI
Use when interpretation is required.
Summarise the commercial context before approval.
Prediction
Use when historical signals may help estimate what is likely next.
Identify which orders may miss their required fulfilment window.
Not every manual process needs AI.
Agents can connect information with approved actions: reading data, finding knowledge, preparing work, creating a task, drafting a communication or triggering a workflow. They require identity, permission, context, defined tools, human approval where appropriate, audit and reconciliation.
The more an AI capability can do, the more important its boundaries become.
Explore Security, Governance & TrustOperational history can contain signals about what may happen next: warehouse backlog, pick wave risk, inventory, capacity, demand, supplier risk or project delivery. Prediction is useful only when there is still time to act.
Explore Predictive IntelligencePlatform discipline
The best integration moves enough information to support the process. Not the maximum amount technically possible.
Development, test, UAT and production each need a clear purpose, controlled deployment, appropriate data, appropriate access and named ownership. The same discipline applies across Dynamics, Power Platform, integrations and AI workflows.
The architecture still needs to work after the project team leaves: documentation, ownership, monitoring, deployment, knowledge, third parties, security, integration, customisation and data. A clever solution that nobody can support is not a good enterprise solution.
Agree the change and its business intent.
Make the change in a controlled environment.
Prove the process, not only the configuration.
A named person accepts the change.
Move it deliberately, not manually and hopefully.
Confirm the outcome in production.
The decision before integration
Integration is not automatically the right answer simply because two systems exist. Decide first whether the dependency should be retained and integrated, replaced, consolidated, retired or deferred.
Some requirements extend beyond the business application itself. Azure and current Microsoft cloud services may support integration, APIs, functions, AI services, identity, data and monitoring where the requirement genuinely justifies it. Not every project needs them.
How the platform meets delivery
Recovery often reveals where the platform stopped behaving like one platform.
Transformation is the point to decide what belongs where.
Accelerated delivery depends on avoiding unnecessary complexity.
Existing Microsoft investment often contains more capability than is being used.
A connected platform needs support across the boundaries between applications.
The more a capability can do, the more important its boundaries become.
Illustrative architecture
These are illustrative shapes rather than recommended architectures. No organisation should assume its own model looks like this.
Illustrative
Illustrative
Illustrative
Cross-platform disciplines
These are not Microsoft products. They are the disciplines that make the ecosystem sustainable.
Who can see and do what, across every application rather than one at a time.
Separated environments, controlled deployment and a named approver for change.
One authoritative home per dataset, with governed representations elsewhere.
Deliberate exchange, with failure handling and reconciliation designed in.
Prove the business process, not only the configuration.
Support across boundaries, because incidents rarely respect product lines.
Capability only counts when people use it to do the work.
The architecture has to be sensible to own, not only sensible to design.
Adoption
Adoption is part of value realisation, not a training task at the end.
Signals the capability has not landed
Commercial architecture
Not all of these apply to every architecture. We do not publish Microsoft prices, and cost should be confirmed against current licensing at the point of decision.
Architecture confidence
Decision checks rather than project bureaucracy. Each can end in proceed, simplify, re-design or deeper assessment.
Check 1
Before design
Do we agree how the organisation should work before choosing the platform?
Confirmed at this gate
Decision
Proceed to architecture · Run a short assessment first
Check 2
Architecture
Is this architecture proportional to the complexity we actually have?
Confirmed at this gate
Decision
Proceed · Simplify the architecture
Check 3
Data and integration design
Is it clear which system owns each dataset, and what genuinely needs to move?
Confirmed at this gate
Decision
Proceed · Re-design the data and integration model
Check 4
Before commitment
Can we run, support, govern and afford this after go-live?
Confirmed at this gate
Decision
Proceed · Reduce scope · Phase the architecture
Shared responsibility
How the organisation should work is a business decision, not a Microsoft configuration.
Someone in the organisation must own each important dataset and its definitions.
A named owner should decide where standard is accepted and where difference is justified.
The people who know the process need time to shape and test it.
Change into production needs a named accountable approver.
Line management ownership is what turns a capability into normal working.
Licence commitments and consumption remain the organisation's to manage.
After go-live
Later change should be a response to the business, not an automatic upsell.
Agree the operating model and the architecture that serves it.
Deliver the capability the operating model actually needs.
Prove it holds under real volume and real exceptions.
Make it the normal way the work is done.
Support it across application boundaries.
Use what is already owned before buying more.
Add capability only when the business case is clear.
Retire what no longer earns its place.
Customer experience
These published customer stories show Dynamics customer relationships, implementation experience and how customers describe working with us. They are not evidence of a particular architecture decision, and they do not prove Power Platform, Fabric, AI, Predictive Intelligence or cross-platform integration outcomes.
Customer video
We transformed our business practices in just 5 months
Hill & Smith describe their Dynamics 365 implementation with InteliSense in their own words.
What it does not prove: Does not establish Recovery, RAPID, Optimise, Support classification. No measured outcome is published with this evidence.
Customer video
Implementing D365 for the British Society of Lifestyle Medicine
A membership organisation describes implementing Dynamics 365 with InteliSense.
What it does not prove: Does not establish Recovery, RAPID, Optimise, Support classification. No measured outcome is published with this evidence.
Customer video
Hear our customers talk about InteliSense
Several customers describe working with InteliSense, in their own words.
What it does not prove: Does not establish Recovery, RAPID, Optimise, Support classification. No verified industry classification. No measured outcome is published with this evidence.
Evidence we do not yet publish
Where we do not yet hold verified customer evidence, we will say so rather than imply it.
Where to start
Orientation only. This suggests a likely starting point for a conversation. It will never tell you that you need a particular Microsoft product.
Choose a situation and a focus. Nothing here decides your architecture.
Not sure which of these applies?
Common questions
Your Microsoft estate
If ERP, CRM, Power Platform, reporting, data or AI have grown independently, we can help clarify where each capability should fit and what should connect.
