Identifying Unused Fields

A table with 200 fields, half of which nobody can attribute anymore. That is no exaggeration. After a few years of operation it is often the normal state. Fields are created when someone needs them and stay when nobody asks anymore. The question is how to separate the wheat from the chaff without destroying anything.

Step one: usage in the configuration

The solution export answers the first round of questions completely. For each field you can check whether it sits on a form. That is in the form definitions. Whether a view shows it or filters by it is in the fetchxml of the views. You can also see whether a business rule or a workflow reads or writes it, and whether a JavaScript mentions its name.

A field that appears in none of these sources is a candidate for cleanup. No more, no less. In a typical grown table, a list of perhaps 50 candidates remains out of 200 fields. Only those need to be discussed at all.

Step two: what the export does not know

Now come the uses that are not in any solution. A field can be populated by an integration, appear in a Power BI report, be read in a flow of a completely different solution or serve as a filter in a marketing list.

Two checks cover most of this. The dependency view of the platform lists what points to the field within Dataverse, even across solution boundaries. You find it on the component under "Show dependencies". And a simple query counts how many records have a value in the field at all. A field with no configuration usage, no dependencies and not a single populated record is as dead as you can determine from a distance.

That leaves the rest: external systems that read via API. None of the checks sees them. That is why every deletion list needs a follow-up question to the colleagues who maintain the interfaces.

Step three: remove with a way back

Even after all the checks, I recommend an intermediate step instead of deleting straight away. Take the field off the forms and out of the views, add a note to the display name, and then wait. A quarter is a good period. It is long enough for monthly and quarterly processes that may need the field after all.

Only then comes the deletion, and deliberately one field at a time instead of in one big batch. If something does break, you want to know which field it was.

The real gain

This exercise is not about storage space. Every field that stays has to be considered, tested and documented in every future change. That is the point. A table that shrinks from two hundred to one hundred and sixty fields is noticeably cheaper with every further rebuild. That is the interest this work pays, and it comes back every year.