Dynamics 365 and Power Platform health check

What I look at

The same list every time, plus whatever you tell me is hurting. Everything below is checked in your environments, not from a questionnaire.

Solution layers and active layers

Which solutions you have, which are managed and which aren't, and what's sitting in the active layer in test and production. Unmanaged changes made directly in production are the most common reason a deployment "works" but a field or form won't change. I list each one and say whether to move it into a solution or remove it.

ALM and pipelines

How a change gets from dev to production. Source control, Azure DevOps or Power Platform pipelines, PAC CLI, solution versioning, who can import what. If releases are manual, I write down what a simple, repeatable pipeline would look like for your setup.

Plugins and flows

Plugin registrations, steps and images, sync versus async, and anything calling an external system inside the save. Power Automate flows: whether they're in solutions, who owns them, error handling, and flows that fail quietly. Plus the plugin trace log and flow run history, which usually tell you a lot. One common find: Update steps with no filtering attributes.

Security roles and access

Roles, business units, teams and field security. Roles that have been copied and tweaked until nobody knows which one does what. Users with System Administrator who don't need it. Where it's simple to tidy up, I suggest a smaller set of roles.

Integrations

Every system Dataverse talks to: finance, ERP, payments, Azure Functions, Service Bus, custom connectors, web APIs. How failures get noticed, whether there are retries and logging, and whether anyone would know if an integration stopped tonight. More on how I build Dynamics 365 integrations.

Connection references and environment variables

The usual cause of "imported fine, doesn't run." I check each connection reference points at the right connection in each environment, that environment variables have values where they need them, and that nothing environment-specific is hard-coded in a flow or plugin.

Power Pages table permissions

If you run a portal: table permissions, web roles, scope (global, contact, account, parent), anonymous access and the Web API settings. This is where data leaks between customers happen, so it gets a careful look.

Performance and licensing

Slow forms, heavy views, too many sync plugins on one table, storage growth. And a sense check that the licences you're paying for match what people actually use.

Upcoming platform changes

Microsoft keeps retiring things, and some of it lands on a fixed date. The one coming up fast: unmanaged developer environments. From 15 November 2026 you can't create new ones. From 15 December 2026 existing ones are suspended, and from 15 January 2027 they're deleted. If your team builds in developer environments that aren't managed, that work needs to be converted to a managed environment or moved out before then. I check your environment list against Microsoft's current deprecation notices and flag anything that affects you, with the date. More detail: what to do about unmanaged developer environments.

What the report looks like

A plain written document, not a slide deck. Usually:

• One-page summary. The state of things in plain English, for whoever signs off the budget.
• Findings. Each one with what I found, where, why it matters and how to fix it. Rated high, medium or low.
• Fix plan. The findings in the order I'd tackle them, with a rough effort for each. Quick wins first, anything risky called out.
• Platform changes. Anything Microsoft is retiring that touches your build, with the dates.
• Walkthrough. An hour or so on the last day going through it with your team, so questions get answered while it's fresh.

You own the report. Hand it to your team, your partner or your next contractor.

Who it's for

• You've inherited a build and nobody left properly documented it.
• Your partner or main contractor has moved on.
• Releases have started to feel risky, or you dread them.
• Something big is coming: a new phase, an upgrade, a new integration or a portal, and you want to know what you're building on.
• You want a second opinion before signing off a partner's work.

It suits organisations running Dynamics 365 CE or Dataverse day to day, often with a small internal team and no senior platform person in-house.

How the five days run

A short kick-off on day one to get access and hear what's worrying you. Then three days in your environments, source control and pipelines, with a few questions to whoever knows the build. Day five is writing it up and the walkthrough. Nothing in your system gets changed. It's a review, not a build.

If the call shows a health check isn't what you need, I'll say so.