Service — Dynamics 365 Customer Engagement
Dynamics 365 Customer Engagement, architected as one system — not five apps bolted together.
Architecture and delivery across Customer Service, Sales, Marketing, Field Service and Project Operations — designed around a coherent data model and integrated cleanly with Power Platform, Azure and the wider Microsoft estate.
The apps, and the seams between them
The data model is the architecture
Most Dynamics 365 difficulty traces back to the data model and the seams between apps — a Sales record that does not line up with the Service case, a Field Service work order that cannot see the project it belongs to. Get the Dataverse model and the integration boundaries right and the rest of the programme becomes considerably calmer.
I architect and deliver across the full Customer Engagement suite:
- Customer Service — case management, knowledge, SLAs, and the routing that connects to the contact centre.
- Sales — pipeline, forecasting, and the lead-to-cash path that touches finance.
- Marketing — journeys, segmentation, and the consent and data model behind them.
- Field Service — work orders, scheduling, assets and the mobile experience.
- Project Operations — resourcing, time and cost, and the join to delivery and finance.
The architecture
One platform, layered deliberately
How I approach it
Fit the platform to the organisation
Dynamics 365 is configurable enough to be built badly in a hundred ways. The discipline is deciding what to standardise, what to extend with Power Platform, what to integrate to Azure or a line-of-business system, and what to leave alone — then writing that down so the delivery team and the next architect can follow the reasoning.
I work from a clear picture of the current estate, design a target architecture that fits the budget and the team, and stay close to delivery so the build matches the design — including the ALM, environment strategy and governance that decide whether the platform is still maintainable in two years.
Example projects
Two D365 CE programmes, at scale
Example 1 — Healthcare · 7,000 users
A mission-critical healthcare provider — 7,000 admin and contact centre CE users
A mission-critical healthcare provider with around 7,000 administrative and contact centre staff working in Dynamics 365 Customer Engagement, with Avaya as the telephony platform. The estate spanned roughly 150 integration points — the kind of environment where the integration architecture matters as much as the application design.
The data architecture was the heart of the work: a delta-migration approach using Kafka streams for change data, Synapse Link replication for analytics, and on-premises SQL replication where systems could not yet move — keeping a live, consistent picture across a large and partly legacy estate without disrupting a service that cannot go down.
Example 2 — Energy · National electricity grid
A national electricity grid company — case and application management
A national electricity grid company needed case management and application management built on Dynamics 365 Customer Engagement, against a genuinely complex set of existing business processes. The first task was to document the As-Is properly — to get an accurate, shared picture of how the work actually flowed before anyone designed anything new.
From there: define the To-Be process — the workflow the organisation should run, agreed with the people who run it — then define the architecture that supports it, and lead the team through build and into go-live. The process design and the platform design had to move together; neither is worth much without the other.
Starting, scaling or straightening out a D365 estate?
A short conversation is usually enough to tell whether the issue is the data model, the integration boundaries, the ALM, or simply scope — and what to do about it.