Dynamics 365 Health Check and Technical Audit

A Dynamics 365 health check is a fixed-scope assessment of a Dynamics 365 Customer Engagement, Power Platform, Business Central or Finance and Operations implementation. Solzet audits configuration, security, performance, data quality, and alignment with business processes to identify risks, waste, and improvement opportunities. The deliverable is a written report and a prioritized action plan covering optimization, cleanup, and roadmap steps. It is an independent, evidence-based read on the state of your system, useful before a major upgrade, after a go live, or when performance is declining.

Yes. Solzet implements Dynamics 365 Business Central and Finance and Operations, alongside Customer Engagement and Power Platform, and we can audit your existing project whoever built it. The assessment covers the extensions and custom code, the data, the integrations, security, performance and upgrade readiness, and ends in a prioritized remediation backlog and a stabilisation plan you own. Where you want the fixes delivered too, we can scope them, but the audit stands on its own.

Four things beyond the standard health check dimensions. The extensions and the AL code inside the ones you own, including whether the source and build route are in your hands. Upgrade readiness: customizations carried over from Dynamics NAV, dependencies on obsolete objects, and the on-premises version position, since Business Central on-premises version 25 or later migrates directly to online and older versions upgrade to 25 first. Data: duplicated master data, posting groups and dimensions that no longer match the chart of accounts, and migrated balances reconciled against the source. And integrations: APIs, the Dataverse connection to Dynamics 365 Sales, virtual tables, and failing job queue entries.

Yes. Solzet runs an independent AL code review of the Business Central extensions you own, on its own or as part of the wider audit. It checks upgradeability (event subscribers against modified or copied base objects and obsolete dependencies), performance (SetLoadFields, FlowFields and CalcFields, locking and long transactions), permission sets, telemetry to Application Insights, test codeunits, CodeCop, UICop, AppSourceCop or PerTenantExtensionCop findings, dependency and version hygiene, and the upgrade path. You receive a findings report with priorities and a stabilisation plan.

Read access to the source repository of every extension you own, the app files installed in production so we can confirm they match the source, read access to a sandbox or a copy of production, and Application Insights access if telemetry is connected. A short call with whoever maintains the code helps us read the exceptions, but the review does not depend on the original developer being available.

The X++ customizations and how much of the standard product they replace rather than extend, with code quality and the route to production. Dual-write and virtual entities where Finance and Operations meets Customer Engagement, including sync errors and conflicts through Dataverse. The lifecycle set-up: environments, how Microsoft updates are tested, and whether the project lives in Lifecycle Services or the Power Platform admin center. And performance: colliding batch jobs, slow forms and reports traced to custom code, integration volumes at peak, and month end runs. The output is the same evidence-backed backlog and stabilisation plan as every other health check.

Yes. That is one of the most common reasons clients call us. Solzet acts as an independent assessment firm and gives you a second opinion on a Dynamics 365 Customer Engagement or Power Platform environment we had no part in building. Independence here is concrete rather than a claim: we did not make any of the design decisions, so we have nothing to defend; the price is fixed before we start and does not move with what we find; every finding names the solution component, security role, query, flow run, trace entry, or record count it rests on so anyone can reproduce it; and the report is yours to send to your incumbent, another partner, your board, or your own team. Where the build turns out to be broadly sound and the real constraint is scope, budget, or an internal decision rather than the partner, we write that down just as clearly.

Yes, with clear limits. For this use the assessment produces an evidence pack: each finding tied to the artifact it rests on, such as a solution layer, plug-in step, flow run, security role, query, or record count; a rating by business risk and remediation effort that separates defects from arguable design choices; a contracted versus delivered map built from the statement of work, change requests, and sign-off records you provide; the supportability and handover position; and a remediation sequence the incumbent or any other supplier can price. It also records what is sound, because a balanced pack is harder to dismiss. It is a technical assessment, not a legal opinion, and your legal adviser draws the contractual conclusions.

No. We do not interpret the legal effect of the contract or advise on termination rights, breach, liability, remedies, or damages, and the report is not an expert report prepared for litigation or arbitration. Where the contract documents are ambiguous about what was agreed, we mark the item ambiguous rather than choosing a reading. The pack gives your lawyer reproducible technical facts to work with; if proceedings are likely, they should decide how any technical expert is instructed before work starts.

It is narrower and deeper. Large systems integrators and global Microsoft partners often assess a whole business applications estate, including organizational change. Solzet assesses the Dynamics 365 and Power Platform environments you name, Customer Engagement, Business Central and Finance and Operations included, with senior consultants reading the solution, code, logs, and data directly, at a fixed price and fixed end date, with no rebuild proposal and a report you own and can act on with any supplier. A larger firm is the better choice when you need a multi-country programme review or a supplier already on an enterprise panel.

There is none. The closing walkthrough covers the findings, the evidence, and the priorities, and then it stops. There is no proposal attached to it and no follow-up sales sequence. If you want us to quote for any of the remediation you have to ask, and many clients never do. The assessment is quoted as a fixed price against an agreed list of environments and apps, with a fixed end date, so nothing about the severity of the report changes what it costs you or earns us. An audit whose price or follow-on work depends on how alarming its own findings are is not an audit.

Five dimensions, each with named evidence and a stated verdict. Technical health reads the environment and solution inventory, the release position against what is deprecated, form and view load timings, plug-in and flow execution times from the trace log and run history, integration failure rates, and capacity consumption. Customization quality reads the solution layers, plug-in and custom API code, form JavaScript, PCF and canvas components, and the path a change travels to production. Data integrity reads duplicate rates, completeness of the columns decisions depend on, stale and orphaned records, reference data consistency, and integration reconciliation against the source. Security posture reads roles, teams, business units, field-level security, sharing, service accounts bound to individuals, DLP coverage, and administrative access. Business process alignment compares the configured processes against how the work is really done, including the spreadsheets and mailboxes people have moved back to. The five converge into a single prioritized remediation roadmap.

One sequenced plan rather than a longer list of worries. Each item carries a severity, a rough effort in days, the dimension it came from, the business consequence of leaving it alone, and a suggested owner. The ordering is deliberate: live security and data integrity exposures first, then the technical health items costing users time every day, then the customization quality work that has to happen before anything else can be changed safely, then the process alignment items that usually need a business decision rather than an engineer. The roadmap also states what we would not do and why, because leaving a working thing alone is easier to recommend when nobody is quoting for the result.

Six things, whoever runs it. A solution and customization inventory that reconciles with what your administrator sees. A plug-in and flow map showing what fires on each record event and which components run under a named person. Data-quality findings that name the table, the rule and the result, so they can be measured again. A security review written as a register of who can see and export what. One prioritized remediation backlog with severity, effort range, dependencies and an owner per item. And a salvage or rebuild recommendation per area, argued from the evidence. If an assessment ends without all six, the remediation that follows is being planned on opinion.

Name the six deliverables as written artifacts due by a fixed date, in an editable format you keep. Require every finding to cite the component, environment and date it rests on. Limit the work to read access, with access removed on a stated date. Fix the fee before work starts and keep it independent of the findings and of any follow-on award. State that you own the report and may share it with any partner, your auditors or your board. Include a walkthrough and a clarification period, and list the environments and apps in scope and anything excluded.

A fixed remediation or rebuild price before anyone has read the environment. Discovery made only of workshops, with no reading of solutions, code, run history or data. No named deliverables at the end of discovery. An assessment that is free only if you also sign the remediation. A rebuild or re-licensing recommendation with no salvage analysis behind it. Unnamed or junior assessors, or a request for administrator write access to do read-only work. And silence on data quality and security. Any one of these means the proposal is pricing a guess.

A health check assumes there is a working system worth improving. Occasionally the evidence shows something else: a build that cannot be made safe to change, an implementation that has stalled rather than slowed, or a situation where the honest recommendation is to move the work elsewhere. We keep that on separate pages rather than blurring the two. Our guide to rescuing a failed or stalled Dynamics 365 implementation covers the root cause families and how delivery is put back on track, and our Dynamics 365 project rescue and takeover service covers the emergency takeover, stabilization, and the fixed scope reset that follows. Running the assessment first is the point, because a decision that large should rest on evidence rather than on frustration.

Six areas by default: configuration and customization, including the Dataverse data model, forms, business rules, apps, plug-ins, and PCF controls; security and access across roles, teams, and field-level security; performance and scalability; data quality and hygiene; business-process alignment; and integrations, environment strategy, and application lifecycle management. We agree the exact scope and the apps and environments included before we start, so you know precisely what the fixed price covers.

Yes. The Power Platform governance and licensing audit is a named, fixed-scope module of the health check, priced per tenant against an agreed number of environments. It is checklist driven and covers unused and abandoned apps and flows, premium connector usage against the Premium and Per App licenses people actually hold, orphaned and duplicate Dataverse environments and the capacity they consume, hidden ownership and key-person risk such as production flows owned by a leaver or bound to a personal account, DLP policy and connector governance, and recoverable storage and license waste. You get a governance register listing every app, flow, and environment with its owner, its last real use, its licensing position, and a recommended action of keep, reassign, or retire.

Score first, then triage. Inventory every app and flow shared beyond its maker from the Power Platform admin center or the CoE Starter Kit. Score each on four factors from 0 to 3: what data it touches, how widely it is shared, whether it writes to a system of record, and whether anyone still owns it, and put anything already implicated in a leak or shared externally at the top regardless of score. Read business criticality separately by asking what stops if it is switched off. Then contain the highest-risk few immediately, formally adopt the business-critical ones into a supported solution and deployment route, and retire the rest with notice and an agreed quarantine period.

Risk decides the speed and criticality decides the action. Contain the handful with the highest risk scores or a leak override straight away by removing wide and external sharing, disabling flows that write to systems of record under personal connections, and applying DLP to the environment. Adopt the assets whose loss would stop a real business process: give them a business and technical owner, move them into a managed environment as a solution, and put their connections on a service identity. Retire everything that is neither critical nor owned, with a dated notice, a contact, and a route to claim it, and keep the exported package until the quarantine period ends.

Capture it before anyone fixes anything. Export the app or solution package, record the sharing list, the connections and the identities they run under, the owner and the environment, and export the relevant activity from the Microsoft Purview audit log for the period in question. Flow run history and audit log retention are limited and depend on licensing, so check current Microsoft documentation and export early. Unshare and disable the app rather than deleting it, and keep a dated record of every containment action taken, because the timeline is part of what compliance and any investigator will ask for.

Send short written updates on a fixed cadence: what the inventory covers so far, the scoring method and the evidence behind the order, what has been contained and when, what evidence has been preserved and where it is stored, what is being adopted or retired and by which date, and what is still unknown. Do not speculate about the extent of an exposure you have not yet confirmed. Whether an incident must be notified to a regulator is a decision for your data protection officer or legal adviser, so give them the facts as soon as you have them rather than after the triage finishes.

Usually not. Rebuilding everything before you know what matters spends effort on assets you will retire. Score and triage the portfolio first, contain the risky few, retire what nobody needs, and then build the foundation around the business-critical set: managed environments, solutions, source control, a service identity for connections, and a repeatable deployment route. Each adopted asset joins that route one at a time, and only the ones that cannot be made supportable in place are rebuilt. The deployment mechanics are in our guide to Power Platform ALM with PAC CLI and pipelines, and the ongoing capability in our guide to a Power Apps Center of Excellence with a nearshore team.

The scoring and containment can be done without buying anything. The Power Platform admin center, the Microsoft Purview audit log where your existing licensing includes it, and the Microsoft CoE Starter Kit are enough to inventory, score, and contain a portfolio, and for a small portfolio a spreadsheet is enough. Where it stops being a one-person job is adoption: moving critical apps into solutions, re-pointing connections, rebuilding the ones that cannot be supported, and setting up a deployment route takes engineering time. That is the part worth costing and taking to budget holders, with the scored list as the evidence.

Contain it in order. First, establish who uses which app under which licence, from the Power Platform admin center, the Microsoft 365 admin center, and the CoE Starter Kit inventory. Second, read what each trial turns into and when, and turn off recurring billing where no decision has been made; trial terms change, so check current Microsoft licensing documentation rather than assuming a duration. Third, pause further sharing and self-service sign-ups without cutting off current users. Fourth, separate apps that genuinely need premium capability from those that can move to standard connectors and SharePoint. Fifth, evaluate per user, per app, and pay-as-you-go options for the premium set with your licensing partner. Then consolidate onto licensed environments and identities, restrict environment creation, and add an approval gate before any app reaches a large audience.

An app needs premium capability when it relies on Dataverse for relational data, row level security, or auditing, on premium or custom connectors such as SQL Server or HTTP, on a model-driven app, or on flows with premium actions or desktop automation. Simple forms, trackers, and approvals often run on SharePoint lists, Outlook, Teams, and Approvals with standard connectors under the Power Platform use rights included with many Microsoft 365 plans. Moving has trade-offs: SharePoint lists have delegation and volume limits and a weaker security model, so sensitive or high volume data should stay on a properly licensed platform. Confirm what your own plans include in current Microsoft documentation.

Use the controls the platform already has. In the Power Platform admin center tenant settings, restrict creation of trial, sandbox, and production environments to administrators and route makers to personal developer environments. Review the tenant settings for self-service trial sign-up and self-service purchase. Apply DLP policies that keep premium and custom connectors out of the default environment. Where Managed Environments fit your licensing, set sharing limits so apps cannot be shared with whole security groups or beyond a set number of people. Then make sharing beyond a handful of colleagues a request with an approver who checks the licence position, the data, and who supports the app.

Yes, and we do the cleanup as well as the audit. The audit produces the register: every canvas app, model-driven app, cloud flow, environment, and connection, with its owner, its last real use, its licensing position, and a recommended action. The cleanup engagement then executes it, covering orphaned and abandoned apps, unused, duplicated, and quietly failing flows, a rebuilt security role model, Dataverse sprawl across environments, tables, and columns, license optimization against actual usage, and a properly deployed Center of Excellence Starter Kit. The deliverable is an actionable cleanup plan with prioritized remediation steps, each carrying an owner, an effort estimate, a risk rating, and a way to undo it. The sequence runs freeze and confirm, reversible retirements, ownership and licensing corrections, consolidation and rebuild, guardrails, then a re-run of the inventory so the recovered licenses and retired items are measured rather than claimed. You can buy the audit on its own and run the cleanup with your own team.

Yes. The governance framework implementation is delivered as working artifacts rather than a policy document. It covers an environment strategy with named environments, owners, lifespans, and a decision about the default environment; written policies for data loss prevention and connector classification, naming and solution standards, data residency and retention, and what a maker may build alone; a request and approval workflow built as a Power Platform application so a maker can request an environment, a premium connector, or a promotion to production and have approval provision it automatically and record it with an owner; ownership, review, and expiry rules including service principal connections and ownership transfer in the leaver process; a solution-based promotion path with pipelines from development to production; and the review cadence, reporting, and maker enablement that keep it running after we step back. The guardrails go on after the cleanup, not before, because enforcing policy against an estate that already breaks it produces noise nobody acts on.

Yes, and we fix the common installation problems while we are there. The Microsoft Center of Excellence Starter Kit is the right tooling for keeping the register true after a cleanup, and it is regularly installed into the default environment, running on a maker personal connection, with the inventory flows failing quietly within weeks of go live. We deploy it into a dedicated environment on service principal connections, get the inventory, compliance, and cleanup components actually running, configure the audit and archive processes against your own retention rules, and hand over the dashboards your administrators will use day to day. It is instrumentation rather than a governance programme, so we set it up to enforce and report on your policies rather than in place of having any.

A governance product will show you dashboards of the sprawl, and if you already own one we are happy to work alongside it. It answers a question you can largely answer already with the Power Platform admin center and the CoE Starter Kit, which Microsoft provides at no additional cost, and it stops where the difficult part begins. No product decides that the app with two users is the one your month end depends on, calls the business owner to agree a retirement, rebuilds a security role model, or rewires forty flows off a departed employee account. Installing another app into a tenant that already has too many apps is not a cleanup. The other thing a marketplace listing cannot offer is independence: we did not build your apps, we do not sell a platform product, the fixed fee does not move with the size of the cleanup we find, and the plan is written so your own team or any other Microsoft partner can execute it.

Almost always a stack of causes rather than one. Work through them in this order. First, time the board in the browser network tab to separate slow server calls from slow rendering. Second, count the resources the tab actually returns, because the board draws a row for every bookable resource the filter allows, including equipment, crews, and leavers nobody removed. Third, narrow the view type and date range, since the payload is resources multiplied by time slots multiplied by bookings and an hourly view across a month is the most expensive request the board can make. Fourth, check the unscheduled requirement panel, which runs its own view query on every refresh and is often left pointing at an unfiltered view. Fifth, list the synchronous plugin steps and real-time workflows registered on the Bookable Resource Booking table, including any on RetrieveMultiple, and read their execution times in the plugin trace log. After that, look at booking and resource cell templates, the auto-refresh interval, the map, booking table volume and indexing, and finally the client machine and network.

Then the problem is in the build rather than the settings, and the remedies are engineering ones. Move synchronous plugins and real-time workflows on booking operations to asynchronous or set-based logic so they stop running on every drag and refresh. Archive closed bookings out of the table the board queries and index the custom columns your filters and views sort on. Virtualize the dispatch view so only the rows and time columns on screen are rendered, which stops the cost scaling with the size of the operation. Where the standard board still cannot give a dispatch team the view they need, we build a purpose-built PowerApps Component Framework control in TypeScript and React with server-side paging, virtualized rendering, and only the columns that team works from. Solzet delivers this through our Dynamics 365 Customer Engagement consulting service, or through our project rescue and takeover service when the customizations causing the problem were left behind by a previous implementation.

Sequence it over roughly 90 days, adjusted to the size of the estate. First, inventory every environment, app, flow, and connection with its owner, and mark what touches regulated data. Second, contain: analyze what the target DLP policies would break, agree fixes or exceptions, then enforce on the regulated data environments and the default environment, and move regulated production flows off personal connections. Third, put the structure in: an environment strategy by purpose, naming and ownership standards, an approved build route, and a maker onboarding path. Fourth, run one full review cycle and keep the evidence, including an exceptions register and a dated plan for the remaining cleanup. Auditors rarely expect a finished cleanup; they expect control over the regulated part and a process that is demonstrably running. The approved build route must exist before freedoms are removed, or makers move to personal accounts and unsanctioned tools and the finding gets worse.

No. A DLP policy is enforced as soon as it applies, and flows that break it are suspended while apps can no longer use the blocked connector combination. The honest equivalent of monitoring is impact analysis before enforcement: compare the connector usage per app and flow from the CoE Starter Kit inventory with the proposed policy, use the DLP editor in the CoE Starter Kit or the impact information in the admin center where available, apply the policy first to a test environment or a small set of environments, fix or grant a documented exception for what would break, announce the date, and only then widen the scope.

Dataverse database, file, and log capacity is pooled at tenant level, but the Power Platform admin center reports consumption per environment. Give every environment a business owner and a cost center in the register, record its consumption each month, and report capacity by owner alongside the actions that reduce it, such as retiring copies of production data in sandboxes and trials, deleting old logs, and archiving attachments. Where you want true chargeback, pay-as-you-go billing policies can link specific environments to an Azure subscription, which changes how those environments are licensed, so it is a decision to make deliberately rather than a reporting fix.

The audit tells you what is actually in your tenant today and what to do about it. A Center of Excellence is the ongoing capability that keeps it that way, with an environment strategy, DLP policies, solution-based ALM, reusable components, and enablement for your makers. The two fit together: the audit produces the inventory and the proposed guardrails, so any CoE you build afterwards is written against real findings rather than in the abstract. Our guide to building a Power Apps Center of Excellence covers that next step, and our Power Platform consulting service covers the build and support work that follows. Neither is an obligation, since the audit and its action plan stand on their own.

The common triggers are before a major upgrade or wave release, so you clean up before you carry problems forward; post-implementation, to confirm the go live left the system secure and performant before you scale it; and whenever performance is declining and you need to know why. It is also the right move when you have inherited a system nobody can fully explain, when security or licensing feels unclear, or when you are deciding whether to optimize the current design or rework part of it.

Yes. We run health checks across the Dynamics 365 Customer Engagement apps, including Dynamics 365 Sales, as well as Customer Service, Field Service, and the wider Power Platform. For a Sales environment that means the lead and opportunity process, business process flows, forecasting and rollups, security roles, data quality in the sales pipeline, and the customizations and integrations around them, assessed against how your sales team actually works.

A written assessment report and a prioritized action plan. The report describes the state of the environment across each dimension in scope, with evidence for every finding. The action plan rates findings by impact and effort and groups them into optimization, cleanup, and roadmap, so you know what to fix now, what to improve next, and what to plan for. It is specific and vendor-neutral enough to hand to your internal team or any Microsoft partner, whether or not Solzet does the follow-on work.

Yes. Solzet is a Microsoft Dynamics 365 and Power Platform consultancy based in Yerevan, Armenia, delivering to clients and partners across Europe, including Germany, and the US, for Customer Engagement, Business Central and Finance and Operations alike. A health check is a read-access assessment, so we run it remotely as a matter of course. We also work on a B2B and white-label basis for other Microsoft partners who want an independent audit of a client environment without introducing a new face.