Dynamics 365 Health Check and Technical Audit
A fixed-price, independent assessment of your Dynamics 365 Customer Engagement or Power Platform environment, including the second opinion buyers ask for when they no longer trust the read they are getting from their current partner. We audit technical health, customization quality, data integrity, security posture, and business process alignment, run a dedicated Power Platform governance and licensing audit of app, flow, and environment sprawl, and hand you a prioritized remediation roadmap. We also do the cleanup and put the governance framework in place afterwards, if you want the fix rather than only the diagnosis. No sales pitch at the end.
Our Dynamics 365 Health Check is a fixed-scope assessment of your Dynamics 365 Customer Engagement (CE) or Power Platform environment. It is also the independent assessment and second opinion buyers ask for when they no longer trust the answers they are getting from the partner who built the system. We audit technical health, customization quality, data integrity, security posture, and alignment with business processes to identify risks, waste, and improvement opportunities, on a fixed price agreed before we start and with no sales pitch at the end. That includes a dedicated Power Platform governance and licensing audit of uncontrolled sprawl: unused apps and flows, non-compliant premium connector usage, orphaned Dataverse environments, and hidden ownership risk. The deliverable is a prioritized action plan covering optimization, cleanup, and roadmap steps, plus the guardrails and Center of Excellence path that stop the sprawl coming back. Where you want the cleanup executed rather than only documented, we also run Power Apps audit and cleanup as a delivery engagement: orphaned apps and unused flows retired safely, security roles and Dataverse sprawl consolidated, licenses rightsized, the Center of Excellence Starter Kit deployed properly, and a governance framework of written policies, an approval workflow, and an environment strategy implemented so the sprawl does not return. This service is ideal before a major upgrade, post-implementation, or if system performance is declining. Solzet is a Microsoft Dynamics 365 Customer Engagement and Power Platform consultancy headquartered in Yerevan, Armenia, running health checks across Dynamics 365 Sales, Customer Service, Field Service, and the Power Platform for clients and partners across Europe, including Germany, and the US, either directly or on a white-label basis for other Microsoft partners.
A health check is an assessment, not a sales pitch. The point is an independent, evidence-based read on the state of your Dynamics 365 or Power Platform system, whether or not any further work follows. We did not build your system, the fixed price does not change with what we find, and the walkthrough at the end delivers findings rather than a proposal. You get a clear diagnosis and a prioritized action plan you can hand to any partner or run internally. Where we find something sound, we say so; where we find risk or waste, we show the evidence and what it would take to put it right.
When to run a health check
Before a major upgrade or wave release
You are about to move to a new release, consolidate environments, or take on a significant change, and you want to know what will break, what is deprecated, and what to clean up first so the upgrade is not carrying old problems forward.
Post-implementation, once the dust has settled
The project went live and the team has been using it for a while. Before you scale it further you want an independent check that the build is secure, performant, and configured the way it should be, rather than assuming the go live left it in good shape.
System performance is declining
Forms load slowly, saves lag, flows time out, or reports crawl, and it is getting worse as data and usage grow. You want to know whether the cause is data volume, customization, integration design, or configuration before it turns into an outage.
You inherited a system nobody can fully explain
A previous team or partner built it, documentation is thin, and you are not sure what customizations exist or which are safe to touch. A health check maps what is actually there so you can own it with confidence.
Security or licensing feels unclear
You are not sure whether security roles grant more than they should, whether users are on the right licenses, or whether the environment carries risk you cannot see. An audit surfaces the exposure and the waste in one pass.
You are choosing whether to optimize or rebuild
Something is not working and you need an honest read on whether the current design can be tuned and extended or whether part of it should be reworked, before you commit budget in either direction.
What the audit covers
Six dimensions across your Dynamics 365 Customer Engagement or Power Platform environment. We agree the exact scope and the apps and environments included before we start, so the fixed price is clear.
Configuration and customization
The Dataverse data model, forms and views, business rules, business process flows, model driven and canvas apps, plug-ins, custom APIs, JavaScript, and PowerApps Component Framework controls. We review how the system is built against how it is meant to be used, and flag customizations that are unsupported, redundant, or fragile.
Security and access
Security roles, teams, business units, field-level security, and sharing. We check whether access matches what people actually need, surface roles that grant more than they should, and highlight the gaps and over-permissions that create risk or audit findings.
Performance and scalability
Form and view load times, slow saves, plug-in and flow execution, query and rollup design, and how the system behaves as data and users grow. We identify the customizations, integrations, and data patterns that are dragging performance down and will get worse at scale.
Data quality and hygiene
Duplicates, incomplete and stale records, inconsistent picklists and reference data, orphaned rows, and storage that is quietly filling with data nobody uses. We assess the state of the data and what cleanup would return the most value.
Business-process alignment
Whether the system still fits how the business actually works, or whether people are routing around it into spreadsheets and email. We compare the configured processes against the real ones and show where the platform and the business have drifted apart.
Integrations, environments, and ALM
Integrations and connectors, environment strategy, solution layering, and how changes are built and released. We check whether the way the system is managed lets you make a change safely, or whether every deployment is a risk.
An Independent Assessment and Second Opinion
A large share of the health checks we are asked for start the same way: someone has stopped believing the answers they are getting about their own system. The partner who built it says performance is normal for the data volume, the customizations are all necessary, and the next phase will fix the rest. Maybe that is true. You cannot tell, because the only people who can read the system are the people whose work is being questioned, and every finding they might report is also an admission against themselves.
That is the situation this service is built for. Solzet acts as the independent assessment firm: a second opinion on a Dynamics 365 Customer Engagement or Power Platform environment from a team with no involvement in how it got that way. We are not auditing our own work, we are not positioning for a rebuild, and we are not going to hand you a diagnosis whose only possible treatment is us.
You do not need to have fallen out with anyone to want this. Boards ask for it before signing the next phase, new IT leaders ask for it in their first quarter, and plenty of internal teams ask for it to confirm in writing what they already suspect. It is equally often used to settle an argument in the incumbent's favour.
What independence actually means here
We did not build it, so we have nothing to defend
Asking the team who built a system to assess that system puts them in an impossible position, because every finding is also an admission. We were not in the room for any of the decisions, so we have no design to justify, no estimate to protect, and no reason to describe a shortcut as a deliberate choice. That is the whole reason a second opinion is worth paying for.
The fee does not move with what we find
The assessment is a fixed price agreed before we start, and it does not change if we find one problem or forty. Nothing about the report earns us more work by being alarming, and nothing about it earns us less by being reassuring. An audit whose price or follow-on depends on the severity of its own findings is not an audit.
We say plainly when your partner is right
Some of the assessments we run end with a build that is broadly sound and a delivery team doing reasonable work under bad constraints, and we write that down as clearly as we write a critical finding. If the real problem is scope, budget, or an internal decision rather than the partner, you should hear that from someone with no stake in the answer.
Every finding carries its evidence
We do not ask you to take a judgement on trust. Each finding names the solution component, the security role, the query, the flow run, the trace entry, or the record count it rests on, so your own administrator or your current partner can reproduce it. That is what makes the report survive a difficult conversation rather than turning into one opinion against another.
The report is yours, and it is written for someone else to use
You own the report and the action plan outright and you can send them to your incumbent, to a rival partner, to your board, or to an internal team, without asking us. We deliberately write them to be actionable by a team that is not us: named components, named risks, and named remediation steps rather than the vague findings that only make sense if you also buy the follow-on programme.
There is no pitch at the end
The walkthrough at the end of the assessment covers the findings, the evidence, and the priorities, and then it stops. We do not close it with a proposal, and we do not follow it with a sales sequence. If you want us to quote for any of the remediation you have to ask, and plenty of clients never do, which is the arrangement we intend.
The evidence behind each verdict
An impartial opinion is only worth having if you can check it. The scope above says what we look at; this says what we read for each of the five assessment dimensions and what conclusion comes out of it, so you can see where every judgement in the report came from and hand the same evidence to anyone else.
Technical health
Evidence we read: Environment and solution inventory, platform and release position against what is deprecated, form and view load timings taken from the browser, plug-in and flow execution times from the trace log and run history, failed run rates on the integrations, and capacity consumption per environment.
The verdict it produces: Whether the system is stable and fast enough for what you are about to ask of it, and which specific measured cost is responsible where it is not.
Customization quality
Evidence we read: The solution layers and where unmanaged layers sit over managed ones, plug-in and custom API code, form JavaScript, PowerApps Component Framework and canvas components, and the deployment path a change actually travels from a developer to production.
The verdict it produces: Whether the build is supportable by another team, which customizations reimplement something the platform already does, and which ones are the reason every change breaks something else.
Data integrity
Evidence we read: Duplicate and near-duplicate rates in the tables the business depends on, completeness of the columns that decisions are made from, stale and orphaned records, reference data and picklist consistency, integration reconciliation against the source, and audit and retention settings.
The verdict it produces: Whether the numbers coming out of the system can be relied on, and where the data is quietly wrong rather than visibly missing, which is the failure mode that damages trust fastest.
Security posture
Evidence we read: Security roles, teams, business units, field-level security, sharing, and access team usage, read against who actually needs what; service accounts and connections bound to named individuals; DLP policy coverage; and administrative access to the tenant and the environments.
The verdict it produces: Where access is broader than the business intends, where a single person is a point of failure or a point of exposure, and what would show up in an audit or an incident before you get to it first.
Business process alignment
Evidence we read: The configured processes and business process flows compared against how the work is really done, the spreadsheets and mailboxes people have moved back to, adoption and usage by team, and the change requests that keep arriving in different words for the same underlying gap.
The verdict it produces: Whether the system supports the business it was bought for, or whether the technical findings are downstream of a design that never matched the process.
The prioritized remediation roadmap
Findings on their own are just a longer list of things to worry about. The five dimensions converge into one sequenced remediation roadmap, because a report that rates thirty items critical has not actually prioritized anything. 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, and the items are then ordered into what to fix now, what to fix next, and what to plan for.
The ordering is deliberate rather than alphabetical. Anything that is a live security or data integrity exposure comes first. Then the technical health items that are actively costing users time every day. Then the customization quality work that has to happen before anything else can be changed safely, because there is no point scheduling six improvements into a build where every release breaks something. Process alignment items come last in sequence and often first in importance, since they usually need a business decision rather than an engineer.
The roadmap also states plainly what we would not do. Where an item is genuinely not worth fixing, or where the honest recommendation is to leave a working thing alone, we say so and give the reason. That is easier to write when nobody is quoting for the result.
Fixed price, fixed scope, and no obligation after it
The assessment is quoted as a fixed price against an agreed list of environments and apps, with a fixed end date, before any work begins. It runs on read access, changes nothing, and does not interrupt your users or your current partner's delivery. You are buying a deliverable with a known cost, not opening a time and materials engagement that grows in proportion to what it discovers.
When it is done, you have the report, the evidence, and the roadmap, and there is no next step you are committed to. Take it to your incumbent and ask them to work through it. Run it with your internal team. Put it out to another partner. The assessment is the product, and it is priced to stand on its own.
When the second opinion says the project is failing, not underperforming
A health check assumes there is a working system worth improving. Occasionally the assessment finds something else: a build that cannot be made safe to change, an implementation that has stalled rather than slowed, or a relationship where the honest recommendation is to move the work somewhere else. That is a different problem with a different shape, and we keep it on separate pages rather than blurring the two.
If you want to understand what recovery involves before you commit to anything, our guide to rescuing a failed or stalled Dynamics 365 implementation walks through the root cause families, how the diagnosis is done, and how delivery is put back on track. Where you have already reached the decision and need someone to assume control of the environment, our Dynamics 365 project rescue and takeover service covers the emergency takeover, the stabilization plan, and the fixed scope reset that follows it.
Running the assessment first is the point. It means a decision that large gets made on evidence rather than on frustration, and if the finding is that the current build is recoverable and the current partner should keep it, that is a perfectly good outcome and we will write it down for you.
Diagnosing and Fixing a Slow Field Service Schedule Board
The schedule board is the most common single performance complaint we are called about, and it is worth a worked example because the usual advice stops at "show fewer records". A board that takes twenty seconds to load, freezes when a dispatcher drags a booking, or times out entirely is almost never one problem. It is a heavy tab configuration sitting on top of synchronous custom code, sitting on top of a booking table nobody has archived. Fixing it in that order is what makes it fast and keeps it fast.
This is the diagnostic we run inside the performance dimension of the health check, in the order that finds the cause fastest. Each step is something your own administrator can run on read access, and most teams find the answer in the first four.
The diagnostic checklist
Time it in the browser before you change anything
Open the board with the browser developer tools on the network tab and reload. You are looking for which call is slow and how slow: the resource retrieval, the booking retrieval, the requirement panel query, or the render that happens after the last response lands. Write the numbers down. If the network calls return in under a second and the page still takes fifteen, the problem is client-side rendering and no amount of server tuning will touch it. Then open a brand new board tab with default settings and time that too. A default tab that is fast tells you the platform is fine and the dispatcher tab is misconfigured, which is the most common outcome and the cheapest to fix.
Count the resources the tab is actually loading
The board renders a row for every bookable resource returned by the tab filter, whether or not that resource has a single booking in the window. Open the tab settings and look at the resource filter: the territory, the resource type, the characteristics, and whether the tab is quietly returning equipment, facilities, pooled resources, crews, and people who left last year alongside the technicians the dispatcher schedules. Dispatch boards that feel unusable are routinely loading several hundred resources so that one person can look at forty. Scope each tab to one dispatcher's real world, keep it in the tens rather than the hundreds, and give each territory or team its own tab instead of building one board that serves everybody badly.
Narrow the date range and the view granularity
The payload is roughly resources multiplied by time slots multiplied by bookings, so the view type on the tab is a multiplier on everything else. An hourly view across a month is the single most expensive combination the board can be asked for, and it is usually a default nobody chose deliberately. Check what the tab opens on, check how many days it spans, and check what the dispatcher genuinely works from, which is very often today and tomorrow. Moving a heavy tab from a monthly hourly view to a daily view is frequently the difference between unusable and instant, and it costs nothing but a settings change.
Check the requirement panel query at the bottom of the board
The unscheduled requirement panel runs its own view query on every board load and refresh, and it is easy to leave pointed at an unfiltered view returning every open requirement in the system. Look at which view the panel uses, how many rows that view returns, what it sorts on, and whether the sort and filter columns are indexed. Replace it with a view scoped to the territory and the statuses that dispatcher works, sorted on an indexed column. Readers who have already narrowed the date range and seen no improvement are usually paying for this query rather than for the board itself.
Audit every plugin and workflow that fires on booking operations
Synchronous plugin steps and real-time workflows registered on the Bookable Resource Booking table run on every create, update, and drag and drop, and steps registered on RetrieveMultiple run on every single board refresh. List the registered steps in the Plugin Registration Tool against the booking, bookable resource, and resource requirement tables, then turn on the Dataverse plugin trace log and read the per-step execution times against a real board refresh. A synchronous step that calls an external service, loops over related records, or runs an unfiltered query is not a background cost here: it is a direct multiplier on every action the dispatcher takes. This is the step that most published advice skips, and it is where the seconds usually are.
Look at what the booking and resource cell templates are pulling in
Booking tooltips, hover cards, and resource cell templates are configurable, and every extra column or related record they display becomes work the board does per card rather than per page. Review the booking template, the resource cell template, and any custom web resources, JavaScript, or embedded controls attached to the board. A tooltip that resolves the account, the primary contact, and the work order product on hover is pleasant to look at and expensive to render across two thousand bookings.
Check the auto-refresh interval and the map
A board tab set to refresh automatically every thirty seconds against a heavy configuration never finishes one load before the next begins, and the dispatcher experiences that as permanent slowness rather than as a refresh. Widen the interval or turn it off on heavy tabs. Then check whether the map is on: plotting every booking and resource location adds geocoding and render work on top of the same data, and dispatchers who never use the map should not be paying for it.
Measure the data volume and the indexes underneath it
Count the booking rows inside the visible window and the total rows on the booking table, including everything closed years ago that nobody has archived. Then check that any custom column used in a board filter, a tab filter, or the requirement panel view has an index behind it. Filtering a multi-million row booking table on an unindexed custom column is a table scan running on every refresh, and it degrades quietly as the table grows, which is exactly why the board was fine last year and is not now.
Rule out the client, the network, and the environment
Reproduce the same tab on a different machine, a different network, and a clean browser profile before concluding the system is at fault. Corporate VPN routing, browser extensions, and underpowered dispatcher hardware all produce a board that is slow for one team and fine for everyone else. At the same time, check whether the environment is hitting service protection limits or capacity pressure from other workloads, because a board is simply the most visible victim of a tenant that is being throttled.
Advanced remediation, from configuration to engineering
The first three of these are configuration and data work you can run yourself. The last three are engineering, and they are the honest answer when the diagnostic shows the board has been asked for something the standard product cannot deliver at your scale.
Split one heavy board into scoped tabs
Most boards are slow because they are trying to be a single view of the whole operation. One tab per territory, team, or shift, each with its own resource filter and its own default view type, gives every dispatcher a board that loads only their world. It is the highest-return change available and it is pure configuration, which is why it comes first.
Move logic off the synchronous path
Where the trace shows synchronous plugins or real-time workflows on booking operations, the fix is to re-engineer them rather than accept them. Anything that does not have to complete before the record is saved moves to an asynchronous step or a queued job, external calls come off the transaction entirely, and per-record loops are rewritten as set-based queries. Real-time workflows on high-volume booking tables are usually better replaced with a properly written plugin than tuned in place.
Archive the booking history and index what you filter on
Closed bookings from previous years do not need to sit in the table the board queries. Archiving or moving them to long-term retention, combined with indexes on the custom columns your filters and views actually sort and search on, restores headroom that no amount of board configuration can. This is the change that stops the problem returning in eighteen months.
Virtualize the dispatch view
When a dispatcher genuinely needs a wide view across many resources, the answer is to stop rendering what is not on screen. A virtualized dispatch surface renders only the rows and time columns currently visible and pages the rest in as the user scrolls, so the cost of the view stops scaling with the size of the operation. The standard board has real limits here, and once you have proven the network calls are fast and the render is not, virtualization is the remaining lever.
Build a purpose-built PCF dispatch control
Where the standard board cannot be configured into something a dispatch team will use, we build the view they need as a PowerApps Component Framework control in TypeScript and React: server-side paging against the Dataverse Web API, virtualized rendering, debounced refresh, and only the columns that team works from. On a Field Service rollout for a European manufacturer we built exactly this, a custom PCF Gantt view of technician schedules for the dispatch board, alongside the standard product rather than instead of it.
Reduce how much the board is asked to do
If dispatchers are scrolling across hundreds of resources by hand to place work, the board is carrying a job that Resource Scheduling Optimization and the schedule assistant should be doing. Getting the underlying scheduling data into a state the engine can use, meaning accurate characteristics, requirements, territories, and geocoded locations, often removes the need for the enormous manual view that was slow in the first place.
When configuration changes are not enough
There is a point in this diagnostic where the answer stops being a setting. If the trace shows synchronous plugins on booking operations, a data model that forces the board to retrieve far more than it should, or a dispatch process the standard board was never designed to support, no amount of tab configuration will fix it. That is a build problem, and it needs someone who can safely change the build.
This is the work Solzet does. Where the schedule board is slow because a previous implementation left unfinished or badly written customizations behind, our Dynamics 365 project rescue and takeover service takes ownership of the environment, stabilizes it, and corrects the scheduling configuration and the code underneath it. Where the board is sound but the dispatch team needs something the product does not offer, our Dynamics 365 Customer Engagement consulting team builds it, including the custom PCF controls that replace a view the standard board cannot render at your scale.
For what that looks like in practice, our Field Service digitization case study for a European manufacturer covers a fifty technician dispatch operation where custom PCF Gantt controls sit alongside Resource Scheduling Optimization on the dispatch board, with the scheduling time and utilization numbers that came out of it.
Power Platform Governance and Licensing Audit
Power Platform sprawl is a specific problem and it gets its own module inside the health check. If makers have been building apps and flows for a couple of years and nobody has kept a register, you now have a tenant where nobody can say with confidence what exists, who owns it, what it costs, or what would break if it stopped. This is a checklist-driven audit that answers those four questions with evidence, and then tells you what to retire, what to reassign, and what to license correctly.
It runs on read access through the Power Platform admin center and tenant analytics. We change nothing and we turn nothing off. Every item comes back with the evidence attached, because the recommendation to retire an app is only useful if the business owner can see why.
Unused and abandoned apps and flows
A full inventory of every canvas app, model-driven app, and cloud flow in the tenant, with the owner, the last launch or last run date, and the number of real users behind it. We separate what is in daily production use from what was built once for a demo, what has been failing quietly for months, and what has a single user who left. Each item comes back marked keep, reassign, or retire.
Premium connector and license compliance
Which apps and flows use premium connectors, custom connectors, HTTP actions, or Dataverse from outside a Dynamics 365 app, and whether the people running them hold the Power Apps or Power Automate Premium or Per App licenses that usage requires. This is where non-compliance hides, and it is far cheaper to find it yourself than at a Microsoft true-up or renewal.
Orphaned and duplicate Dataverse environments
Every environment in the tenant, its type, its owner, its capacity consumption, and whether anything in it is still live. Trial, sandbox, and personal productivity environments accumulate quietly, hold copies of production data, and consume database and file capacity you are paying for. We flag which can be retired, which need converting, and which need an owner.
Hidden ownership and key-person risk
Production automation owned by one named individual, connections bound to a personal account rather than a service principal, flows still owned by leavers, and apps with no documented business owner. These do not show up as errors until the person is gone or the password changes, and then a process stops with nobody able to fix it.
DLP policy and connector governance
The data loss prevention policies in force across each environment, whether the business and non-business connector classification matches how the platform is actually used, and how open the default environment is. We show where a maker can currently move company data into a personal or consumer service without anyone approving it.
Capacity, storage, and license waste
Dataverse database, file, and log capacity by environment, add-on capacity being bought to cover cleanup nobody has done, and the split between Per App and Per User licensing against actual usage. The output is the specific, recoverable waste, named with numbers rather than described in general terms.
The fixed-scope deliverable
The governance and licensing audit is scoped and priced upfront, per tenant, with an agreed number of environments. You know the price and the timeline before we start and it does not move. What you get back is a governance register listing every app, flow, and environment in scope with its owner, its last real use, its licensing position, and a recommended action of keep, reassign, or retire.
Alongside it comes a remediation plan sequenced by what it recovers and what it costs, a named list of the compliance exposures to close before your next renewal, and a proposed set of guardrails: the environment strategy, the DLP policies, and the ownership rules that stop the sprawl returning within a year. It is written to be run by your own team or any Microsoft partner, not just by us.
From audit findings to a Center of Excellence
An audit tells you the state of the platform today. Guardrails are what keep it that way. The register and the proposed guardrails from this audit are the natural starting point for a Center of Excellence, because you are no longer guessing at policy in the abstract: you are writing rules against a real inventory and real findings.
If you want to take that step, our guide to building a Power Apps Center of Excellence with a nearshore team walks through governance, ALM, reusable frameworks, and knowledge transfer, and how a senior team from Yerevan plugs into yours to stand it up. For the build and support work that follows, see our Power Platform consulting service. There is no obligation to take either: the audit and its action plan stand on their own.
Power Platform Health Audit & Governance Remediation
Teams looking for Power Apps audit and cleanup services are usually asking for two things at once. They want somebody independent to tell them what is actually in the tenant, and they want that somebody to then clean it up and make sure it does not come back. The section above is the first half: the register, the evidence, and the findings. This is the second half, which is the cleanup itself and the governance framework that goes on afterwards. Solzet does both, and you can buy either one without the other.
It matters that the same people do the audit and the remediation, because most of what makes a cleanup difficult is not deciding what to delete. It is knowing that the flow with two users a month is the one finance closes the books with, that the app nobody has opened since March is embedded in a Teams channel, and that the security role somebody wants removed is the only thing granting a department read access to its own records. That context comes out of the audit, and it is the reason a cleanup done by the team that ran the assessment is safer and faster than one handed to a stranger with a spreadsheet.
All of it runs the same way as the assessment: fixed scope agreed upfront, nothing removed without an owner confirming it, and every step reversible until you say otherwise.
What the cleanup actually covers
Six areas, written as the remediation rather than as the finding, because knowing you have four hundred apps is not the hard part. Each one is scoped against your own register, so the effort is quoted from real counts rather than from an average.
Orphaned and abandoned Power Apps
Apps with no owner, no active users, or an owner who left the company. Cleanup is a procedure rather than a delete key: we confirm the app has no live consumers from usage telemetry, trace anything embedded in Teams, SharePoint, or a model-driven app that still points at it, notify the business area, export a package so the build is recoverable, remove the app from circulation, and only then delete it after an agreed quarantine period. Apps that turn out to be genuinely in use get a named owner and a supported home instead of a retirement.
Unused, duplicated, and quietly failing flows
Cloud flows fall into four groups and each gets a different action. Flows that have not run in months are turned off before they are deleted, so anything that fires annually surfaces rather than disappearing. Flows failing silently get triaged into fix, retire, or rebuild, because a flow that has failed every night for six months is a broken process somebody has already worked around manually. Near-duplicate flows built by different makers for the same job are consolidated into one owned version. And flows running on a personal connection get rewired onto a service principal or a shared connection reference so they stop depending on one person's account.
Security roles and the access model
Cleanup here means rebuilding rather than trimming. Tenants that have grown organically accumulate cloned roles with one column changed, direct record shares that nobody can explain, and users holding four overlapping roles because each new requirement added one. We rebuild the model from a minimum set of composable roles mapped to real job functions, replace individual sharing with team ownership, remove the standing administrative access that has been sitting on ordinary accounts, and prove the result against a matrix of who should be able to do what before anything is switched over.
Dataverse sprawl across environments, tables, and columns
Personal productivity and trial environments holding copies of production data get consolidated or retired, with the data extracted first where anyone still needs it. Inside the environments that remain, we deal with the tables three teams built for the same concept, the columns nobody has written to since the year they were created, and the unmanaged layers sitting over managed solutions that make every future release unpredictable. The result is fewer environments, one place per concept, and a solution structure that can actually be deployed.
License optimization
The cleanup usually pays for itself here. We rightsize Per App against Per User assignments to how people actually use the platform, remove premium dependencies where a standard connector or a Dataverse-native approach does the same job, reclaim licenses attached to retired apps and departed users, and release add-on capacity that was bought to cover a cleanup nobody ran. Where usage genuinely requires premium licensing that is not in place, we say so plainly and put it right, because finding your own non-compliance is far cheaper than having it found for you at renewal.
CoE Starter Kit deployment and the inventory behind it
The Microsoft Center of Excellence Starter Kit is the right tooling for keeping the register true after the audit, and it is regularly installed badly: dropped into the default environment, running on a maker's personal connections, with the inventory flows failing quietly within weeks. 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 admins will use. It is a toolkit rather than a governance programme, so we set it up as the instrumentation for the policies below rather than as a substitute for them.
The deliverable: an actionable cleanup plan, in order
The output of this work is a sequenced plan rather than a list of everything that is wrong, and each step carries its owner, its effort, its risk rating, and how to undo it. The order below is the one we use, and it is deliberate: the safe, reversible work goes first and recovers most of the value, and the guardrails go on last, once there is a clean estate for them to hold.
Freeze the drift and confirm the register
Before anything is removed, we agree a short freeze on new production apps and flows outside the process, and walk the register from the audit past the business owners. Owners correct it, and they always correct something: the app that looks abandoned but runs one critical monthly task, the flow with two users who happen to be the finance team. Cleanup that skips this step is how a company deletes something important and stops trusting the whole exercise.
Wave one, the reversible retirements
Everything with no users, no runs, and no owner claim. Packages exported, items disabled rather than deleted, quarantine period agreed, nothing irreversible. This wave is deliberately first because it is the largest count, the lowest risk, and it clears the noise so the remaining decisions are about real assets. It also proves the process is safe before anyone is asked to trust it with something that matters.
Wave two, ownership and licensing corrections
Everything that is staying gets a named business owner and a technical owner, personal connections move onto service principals or shared connection references, and license assignments are corrected against actual usage. Nothing is deleted in this wave. It is the one that removes the key-person risk and recovers the recurring cost, which is usually where the return on the whole engagement sits.
Wave three, consolidation and rebuild
The work that needs engineering rather than administration: duplicate apps merged into one owned version, the security role model rebuilt and cut over, tables and environments consolidated, unmanaged layers resolved, and the handful of business-critical apps built by someone who has since left rebuilt properly so they can be supported. Each item is scoped, estimated, and scheduled separately, because this is real delivery work and pretending otherwise is how cleanup programmes stall.
Wave four, the guardrails go on
Only once the estate is clean do the policies, the environment strategy, and the approval workflow described below get switched on. Applying guardrails to a tenant that has not been cleaned means enforcing rules against hundreds of items that already break them, which produces noise nobody acts on and a policy everyone learns to route around.
Re-run the inventory and hand it over
We re-run the inventory against the starting register so the recovered licenses, retired items, closed compliance gaps, and reassigned ownership are shown as measured numbers rather than claims. Your team gets the running CoE tooling, the written policies, and the review cadence, and the plan states clearly what is left, what we chose not to touch, and why.
The governance framework we implement
A cleanup with no governance behind it buys you about eighteen months. This is the framework we put in place so the estate stays in the state we left it, delivered as working artifacts rather than as a policy document: the environments exist, the policies are switched on, the approval workflow runs as an app, and your team knows how to operate it.
An environment strategy people can follow
Named environments with a stated purpose, an owner, a lifespan, and a rule for who can create what where: production environments per business capability, development and test environments that mirror them, a properly governed space for personal productivity building, and a decision about the default environment, which in most tenants is the single largest source of the sprawl. The strategy includes provisioning and decommissioning as routine operations rather than as favours from an administrator.
Written policies rather than folklore
Data loss prevention policies per environment tier with a connector classification that reflects how your business actually works, naming and solution standards, data residency and retention rules, and a plain statement of what a maker may build alone, what needs review, and what is off limits. Each policy is one page, is owned by a named person, and says what happens when it is breached. Policy that exists only in the heads of two administrators is not policy.
A request and approval workflow that is faster than going around it
We build the intake as a Power Platform application, because a governance process that runs on email is a governance process people bypass. A maker requests an environment, a premium connector, a promotion to production, or a data source through a form; the request routes to the right business and technical approver with the information they need to decide; approval provisions the thing automatically and records it in the register with its owner attached. The design target is that the approved route is quicker than the unapproved one, which is the only version of this that survives contact with a busy business.
Ownership, review, and expiry rules
Every app, flow, environment, and connection carries a named business owner and a technical owner. Production automation runs on service principals rather than individual accounts. Ownership transfers are part of the leaver process rather than discovered afterwards. Assets that go unused for an agreed period enter a review and then an archive path automatically, so the estate cleans itself continuously instead of needing another audit in two years.
A supported promotion path from a personal build to production
Solution-based application lifecycle management with pipelines from development through test to production, source control for the things that warrant it, and a clear line where an app crosses from something a maker owns into something the platform team supports. Most citizen development goes wrong at exactly that boundary, so we define what an app has to have before it crosses: an owner, a data model that holds, error handling, and a supportable build.
The people and the cadence that run it afterwards
Governance is an operating rhythm rather than a document set. We define the review cadence, the small group that approves and prioritizes, the monthly reporting from the CoE tooling, and the maker enablement that gives people a safe way to build what they need. Then we train your team on it and step back. If it only works while we are in the room, it does not work.
Why this is consulting work rather than something you install
Search for Power Apps audit and cleanup and a good deal of what comes back is a marketplace listing: a governance product you install into your tenant, on a per user subscription, that will show you dashboards of the sprawl. Those tools are not useless and we are happy to work alongside one you already own. But they answer a question you can already answer with the admin center and the Center of Excellence Starter Kit, which Microsoft gives you at no cost, and they stop exactly where the difficult part starts. No product decides that the app with two users is the one the month end depends on. No product calls the business owner, agrees the retirement, rebuilds the security role model, or rewires forty flows off a departed employee's account. Buying another app to install into a tenant that already has too many apps is not a cleanup.
The other thing a marketplace cannot give you is independence. We did not build your apps, we do not sell a platform product, and we are not defending anyone's previous decisions, so the register comes back saying what it says. The fee is fixed before we start and does not move with what we find, which means nothing about the size of the cleanup earns us more, and the plan is written to be run by your own team or any other Microsoft partner if that is what you prefer.
For the build and support capacity behind the remediation, meaning the developers who rebuild the apps, rewire the flows, and stand up the approval workflow, see our Power Platform and Power Apps developers. Where you want the ongoing capability rather than a one-off cleanup, our guide to building a Power Apps Center of Excellence with a nearshore team covers how a senior team from Yerevan runs it alongside yours. And where the estate is not merely untidy but the delivery behind it has stalled or been abandoned, that is a different engagement, covered by our Dynamics 365 project rescue and takeover service.
How the health check works
A fixed-scope, evidence-based assessment that ends in a prioritized action plan. It runs on read access and changes nothing in your system.
Agree a fixed scope and get read access
We agree upfront which environments and apps are in scope, what the assessment will and will not cover, and the fixed price and timeline for it. You give us the read access we need, and the health check runs without disrupting your users or changing anything in the system.
Audit the environment against each dimension
We work through configuration and customization, security and access, performance and scalability, data quality, business-process alignment, and integrations and ALM. We examine the real solution rather than the story around it, and we record evidence for every finding so nothing rests on opinion alone.
Rate and prioritize the findings
Each finding is rated by impact and effort and tied to a business outcome, so a critical security gap and a low-value cleanup item are not treated the same. You can see which issues threaten stability or compliance now and which are opportunities to reduce cost and friction over time.
Deliver a prioritized action plan
The deliverable is a written report and a prioritized action plan covering optimization, cleanup, and roadmap steps: what to fix now, what to improve next, and what to plan for. It is specific enough to hand to any partner or run with your own team, and it stands on its own whether or not Solzet does the follow-on work.
Walk you through it and agree next steps
We review the findings and the action plan with your team so the priorities and the evidence are clear, answer questions, and, if you want it, scope the remediation and optimization work. There is no obligation to have us do the follow-on; the assessment is the product.
What you get back
The health check is a concrete deliverable, not a vague conversation. You end with a written report and a plan you can act on with any team or partner.
A written assessment report
A clear account of the state of your Dynamics 365 or Power Platform environment across every dimension in scope, with evidence for each finding rather than a list of assertions.
A prioritized action plan
Findings rated by impact and effort and grouped into optimization, cleanup, and roadmap, so you know what to fix now, what to improve next, and what to plan for, each tied to a business outcome.
Risk, waste, and opportunity, named
The security gaps and stability risks that need attention, the licensing and storage waste you can recover, and the improvement opportunities that would make the system faster and easier to use.
A plan you can act on with anyone
The report is specific and vendor-neutral enough to hand to your internal team or any Microsoft partner. If you would like Solzet to deliver the remediation, we can scope it, but the assessment stands on its own.
Frequently Asked Questions
What is a Dynamics 365 health check?
A Dynamics 365 health check is a fixed-scope assessment of a Dynamics 365 Customer Engagement or Power Platform environment. 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.
Do you provide an independent assessment if we no longer trust our current Dynamics 365 partner?
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.
Is there a sales pitch at the end of the health check?
No. 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.
What does the independent assessment method actually look at?
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.
What is in the 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.
What if the assessment finds the project is failing rather than underperforming?
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.
What does the health check audit cover?
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.
Do you audit Power Platform governance and licensing sprawl?
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.
Do you provide Power Apps audit and cleanup services?
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.
Can you implement the governance framework, not just recommend one?
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.
Do you deploy and configure the CoE Starter Kit?
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.
Should we buy a governance app from the marketplace instead of hiring a consultant?
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.
Why is our Dynamics 365 Field Service schedule board so slow?
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.
What can we do if configuration changes do not make the schedule board fast enough?
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.
How is this different from setting up a Center of Excellence?
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 with a nearshore team 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.
When is the right time to run one?
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.
Does the health check cover Dynamics 365 Sales?
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.
What do we get at the end?
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.
Do you deliver health checks in Germany and the rest of Europe?
Yes. Solzet is a Dynamics 365 Customer Engagement and Power Platform consultancy based in Yerevan, Armenia, delivering to clients and partners across Europe, including Germany, and the US. A health check is a read-access assessment, so we run it nearshore and 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.
Want an honest read on your Dynamics 365 system?
Solzet runs fixed-price health checks of Dynamics 365 Customer Engagement and Power Platform environments, ending in a prioritized remediation roadmap you own outright. We did not build your system and we are not pitching for the follow-on work. Tell us what is in scope and we will give you an independent, evidence-based second opinion, directly or on a white-label basis for your team.