Dynamics 365 Health Check: What We Look At (Our Inspection Checklist)

When someone asks about the CE Health Check, the most common follow-up question is: "What exactly do you look at?" It's a fair question. If you're going to spend $2,500 and give a consultant access to your CE environment for five business days, you should know what they're doing in there and what you'll have at the end.

The short answer is that we review everything that can affect how well D365 CE is working for your business — security, data, automation, licenses, adoption, and integrations. Below is the full breakdown of each area, what we're specifically looking for, and the red flags that tell us a problem is more serious than it initially appears.

This isn't a marketing document for the engagement. It's a practitioner's honest accounting of what a structured CE audit covers, written for the business owner who wants to know what they're getting before they sign anything.

What Triggers a CE Health Check

In my experience, clients come to a Health Check via one of four routes:

• They inherited a CE deployment they didn't build. New ops manager or CTO, took over a system that "works mostly" but feels unstable. Nobody fully understands the configuration decisions that were made.
• They had a go-live that never fully delivered. CE is live, adoption is mediocre, reps work around the system, pipeline meetings are tense. The implementation vendor has moved on.
• They want to add something — AI, a new module, Power Platform — and want to know whether the foundation is solid before investing more.
• Costs are higher than expected. License renewals, extra storage charges, per-flow Power Automate billing, or Copilot add-on costs have grown in ways nobody planned for.

All four routes are valid. The scope of the Health Check is the same regardless of which one brings you in — a full environment review, not a targeted investigation of one symptom.

Security Roles and Access Control

Security role configuration is the area that produces the most immediate business risk when it's wrong. CE uses a role-based access model where each user is assigned one or more security roles that define what records they can see, create, edit, and delete. When this isn't set up correctly, you get one of two problems: people can see data they shouldn't (most common), or people can't do their job because their permissions are too restrictive (frustrating and usually surfaced quickly).

What we specifically examine:

• How many custom security roles exist, and whether each one has a documented business rationale
• Whether the "System Administrator" role is being used as a catch-all for users who just need elevated operational access — this is a common shortcut with serious compliance and data integrity implications
• Whether field-level security is used for sensitive data (contract values, salary data, personal information) and whether those settings are configured correctly
• Whether the current role assignments reflect the actual org structure, or whether they reflect an org structure that no longer exists
• Team-based ownership vs. user-based ownership — a common source of visibility problems in organizations that have changed their team structure since go-live

Data Hygiene and Model Integrity

Data quality is the most underappreciated dimension of a CE health review, and the most consequential one for any AI or automation capability you want to build. The audit here covers both the structural integrity of the data model and the quality of the actual data in it.

What we examine on the structural side:

• Custom entity usage — are there custom entities or tables that were built for a requirement that was later solved a different way? These become orphaned data stores that consume storage and confuse new users.
• Custom field proliferation — CE environments that have been through multiple implementation phases often accumulate fields that were created for one project, never used after it, and left in the schema. We count them, assess whether they're still needed, and flag the ones that can be cleaned up.
• Option set consistency — OptionSet values (the dropdown choices on fields like Lead Source, Industry, Stage) become inconsistent when multiple people have edited them over time. This is one of the primary drivers of unreliable reporting.
• Duplicate detection rule configuration and whether duplicates are accumulating

On the data quality side, we look at:

• Account and contact record completeness — what percentage of accounts are missing critical fields (email, phone, address, account owner)?
• Opportunity stage distribution — does the distribution of open opportunities across stages match what a real sales pipeline looks like, or is it concentrated in early stages (everyone's afraid to qualify out) or late stages (sandbagged deals)?
• Activity logging rates — are reps logging calls, emails, and meetings against their opportunities and accounts? This is the leading indicator of whether your CE data is useful or decorative.
• Stale records — how many leads, opportunities, or cases haven't been touched in 90+ days? These either need to be worked or closed, and in many environments they're inflating pipeline numbers and making reports unreliable.

Automation and Workflow Debt

Automation debt is the accumulation of workflows, flows, and plugins that were built for requirements that have since changed — or that were built incorrectly and are running in ways nobody fully understands. It's the most dangerous category we review because automation failures can corrupt data silently.

What we look at:

• Classic workflow inventory — are there still active classic workflows (the pre-Power Automate automation engine) running in the environment? Classic workflows are being deprecated by Microsoft. Organizations that haven't migrated them are accumulating technical debt with a hard deadline.
• Power Automate flow health — we enumerate production flows, check their run history for consistent failures, and identify any flows that are failing on a regular basis but haven't been noticed because nobody gets an alert.
• Plugin inventory — custom plugins are the most powerful and most dangerous customization option in CE. We review every registered plugin, its trigger conditions, and its documented purpose. Undocumented plugins with unknown triggers are a risk register item until they're understood.
• Business rule audit — business rules that conflict with each other or with Power Automate flows can produce inconsistent field behavior that reps experience as "the system is weird." We map all active business rules and check for conflicts.
• Automation coverage gaps — requirements that should be automated (status updates, notification triggers, record assignments) but are being handled manually because the original implementation missed them.

License Usage and Waste

License audits are among the most financially impactful findings in a Health Check. CE license costs compound monthly, and unused or misallocated licenses are money out the door every billing cycle.

What we examine:

• Users assigned full Enterprise licenses who haven't logged in during the past 30, 60, or 90 days — inactive users who have left the company but weren't deprovisioned, or active employees who were given CE access "just in case" and never adopted it.
• Users assigned Enterprise licenses who only need Team Member access — the read-only or limited-edit CE license that costs a fraction of the full Enterprise price. If a user's actual CE usage is limited to updating a status field and viewing reports, they may not need a $105/month license.
• Copilot add-on assignments — at roughly $50/user/month, Copilot licenses assigned to users who haven't used the feature in the past month represent a specific, addressable cost.
• Storage consumption vs. need — CE tenants often accumulate email attachment storage and bulk import history that inflates their database size without business value. Archiving or purging this can reduce storage overage charges.
• Power Automate licensing — the difference between per-flow and per-user licensing has a right answer that depends on how many flows you're running and how many users trigger them. Most organizations aren't optimally licensed here.

Adoption Metrics and Usage Patterns

A technically correct CE configuration that nobody uses is a failed implementation. Adoption analysis is the human side of the Health Check — understanding not just whether the system is configured well, but whether users are actually working in it the way it was intended.

What we examine:

• Daily active user counts vs. licensed user counts — what percentage of licensed users logged in on an average workday in the past month?
• Activity creation rates — are sales reps logging phone calls? Are service reps updating case notes? Is the activity log growing at a rate consistent with the team's actual work volume?
• Record creation and update patterns — are new leads, opportunities, and accounts being created in CE, or are they landing somewhere else first and being entered into CE after the fact (or not at all)?
• Mobile app usage for field teams — for Field Service deployments, we look at whether technicians are using the mobile app for work orders or whether dispatch is still happening via phone and the CE record is being updated manually after the fact.
• Report and dashboard usage — who's actually opening the reports that were built, and which ones haven't been viewed in 90+ days? Unused reports are a signal that the data they're supposed to show isn't trusted or useful.

Low adoption findings typically point back to one of three root causes: the configuration doesn't match how the team actually works (a discovery failure from the original implementation), the team wasn't adequately trained, or there's no management accountability for system usage. The first two are fixable. The third is a business culture issue, not a technology issue — and we say so plainly in the findings report.

Integration Health

For CE environments with external integrations — ERP, marketing automation, telephony, accounting — integration health is part of the audit. Integration failures are often invisible until they cause a visible business problem.

What we examine:

• Integration connector authentication status — many integrations authenticate via tokens or service accounts that expire. Token expiration is one of the most common causes of "silent" integration failures.
• Sync error queues — both Microsoft's native Dynamics 365 connectors and third-party integration platforms (KingswaySoft, Scribe, Logic Apps) maintain error logs. We review these for volume and patterns.
• Data sync latency — is data moving between CE and integrated systems at the expected frequency? A "real-time" integration that's actually running on a 4-hour delay creates operational decisions made on stale data.
• Duplicate or conflicting record creation — bidirectional integrations that aren't designed with a clear "system of record" rule for each data type frequently produce duplicate records in both systems. We look for this specifically in account and contact sync patterns.

The Red Flags That Change the Scope of a Project

Most Health Check findings fall into the "fixable with 4–8 hours of work" category. A few findings represent more serious structural problems that change the conversation from "tune this up" to "rebuild this layer." These are the ones worth calling out explicitly:

• A custom data model that doesn't match the standard CE schema. If the original implementation created custom tables for things CE handles natively — or built CE on top of a data model that was designed for a different system — subsequent changes become exponentially harder. This is the most expensive type of technical debt.
• Legacy plugins running on deprecated APIs. Microsoft updates CE's platform regularly, and plugins written against old API versions can break without notice. Any plugin calling a deprecated method is a ticking clock.
• A security role structure built entirely of custom roles with no relationship to Microsoft's default role hierarchy. This means every future Microsoft update to standard roles has to be manually reconciled with the custom structure. It also usually means the original implementation team didn't understand the CE permission model.
• Bulk data that was imported incorrectly and has been live long enough to be referenced everywhere. Incorrect data that's been in CE for 18+ months has propagated through activity records, related entities, and reports. Cleaning it is possible but expensive and time-consuming. The risk register entry for this type of finding is explicit about the downstream cost.

What You Receive at the End

The Health Check deliverable package is fixed-scope and delivered on day five:

• Written findings report. Every issue identified, organized by category (security, data, automation, licenses, adoption, integrations). Each finding has a description of what we found, why it matters, and the effort level to resolve it.
• Risk register. Findings ranked by business impact — not by technical severity, by what actually affects revenue, compliance, or operational reliability. High-impact items get their own risk entry with a clear escalation path.
• Quick-win list. Items that can be resolved in under two hours of configuration work, separated from the larger project items. These are the things you can act on immediately after the debrief call.
• Prioritized 90-day remediation roadmap. The full remediation plan, sequenced by priority and interdependency. What to fix first, why, and roughly how long each item takes.
• Leadership summary. A one-page version for stakeholder or board communication — what the overall health of the environment is, the top risks, and the recommended path forward.
• 60-minute debrief call. We walk through the full findings together, answer questions, and align on immediate next steps. This call typically produces three to five decisions — things to act on this week, things to schedule for next month, and things to defer.

The $2,500 fee is credited in full if you start a retainer within 30 days of the Health Check delivery. Many clients do — because the roadmap gives us a clear starting point and the engagement model is already established.

Starting a Health Check

The engagement starts with a 30-minute intake call to confirm access requirements and gather context on your environment and top-of-mind pain points. From there, we need delegated admin access to your CE environment — we'll document exactly what access level is needed before we begin.

If you're already thinking through this and want to know whether the Health Check is the right first step for your situation, the fastest way to find out is a short call. See the full CE Health Check offer page for scope details, pricing, and how to get started.

You might also find our post on D365 CE implementation costs in 2026 useful if you're trying to understand how a Health Check fits into the broader cost structure of running CE — and our AI for small business CRM use-cases post if you're thinking about what to build once the foundation is solid.