Finding Dead Components in Dynamics 365

Every solution that lives longer than two years contains components that no longer do anything. A field that can no longer be reached from any form. A script that no event calls anymore. A workflow that has been deactivated for years. Together they make a solution confusing, without anyone being directly accountable for it.

The four typical kinds of ballast

Orphaned web resources. A JavaScript sits in the solution but is not referenced by any form or any ribbon. This is the easiest case to find, because the references can be read directly from the solution itself. One place that is easy to overlook: SiteMap entries that point to web resources by URL, as described in SiteMap XML explained.

Unused fields. A field exists but does not appear on any form or in any view. It can still be populated, for example through an integration or a flow. Caution is needed here, because read operations, for example from Power BI, can also access the data.

Deactivated processes. Workflows and flows set to inactive. Some were paused on purpose, others are leftovers of a discontinued procedure. From the outside, both look the same. Deactivated business rules are a special case of this, covered in removing old business rules.

Duplicate views. Two views with the same query and different names. This happens when someone copies an existing view instead of adapting it.

Why deleting is harder than it looks

The decisive limitation: a solution export only shows what happens within this one solution. A web resource that no form references here may be used by another solution in the same environment.

The same applies to fields. They may not be displayed on the form, but written by a flow, evaluated by a report or populated by an interface. None of this is in the solution in which the field is defined.

That is why the honest statement is not "this component is dead", but "this component is not referenced anywhere within this solution". The difference sounds academic, but it decides whether something breaks when you delete it.

A pragmatic approach

This is how I would go about it.

First determine the candidates from the solution: unreferenced web resources, fields without use on forms or views, deactivated processes and duplicate views.

Then check the list against what the export does not know. For fields, that means a look into the database: does the field contain any values at all? A field without form usage and without a single populated record is a very safe candidate.

And finally: do not delete right away, but deactivate or rename. A field whose display name gets a prefix such as "obsolete" disappears from everyday use but remains recoverable. If nobody has noticed anything after a quarter, it can go.

The benefit

The obvious gain is clarity. The less obvious one: every removed component is one that no longer has to be checked during future changes. In a migration or a larger refactoring this pays off directly, because the number of objects to assess gets smaller. The broader economics behind this are the subject of why solution hygiene saves time and money.

The order remains important: measure first, then assess, then remove. Whoever starts by deleting will sooner or later break something that someone else still needed.