Dependencies and deletion

What it does

Dataverse recalculates dependencies on every operation against a solution component, and uses them to refuse anything that would leave the system inconsistent. It's why a managed solution can be installed and uninstalled cleanly, and it's why you can't delete that column.

Key facts

Three kinds. Internal dependencies are managed by the platform — one component can't exist without another. Published dependencies are created when two components are related and then published. Unpublished dependencies apply to the draft version of a component being updated, and become published dependencies once published.
The enforced behaviours: deletion is blocked if anything depends on the component; export warns about missing components; import fails if required components are neither in the solution nor already in the target.
On managed import, every required component must match the package type. A managed component can only depend on another managed component.
Internal dependencies can cascade into published ones that still need manual work. Delete a primary table and you can't finish until you remove the lookup column from the related table's form and publish that form.
The $webresource: directive is what creates the dependency between ribbons or the sitemap and their web resources. Reference a web resource any other way and no dependency is tracked.
Web resource to web resource references via relative links — an HTML page pulling in a CSS or script file — are not tracked as solution dependencies at all.
Global choices create a published dependency when a choice column references them. You can't delete a global choice that's in use.
Processes create a published dependency on everything they reference, plus one on their primary table. Same pattern for plug-in registrations, email templates and reports.
Only security roles from the environment business unit can be added to a solution, and only by a user with read access to them.
Show Dependencies on a component surfaces all of this in the UI, and there's a Dependency table with messages for doing it programmatically before a delete or an uninstall.

When to use / skip

You don't choose to use dependency tracking, you choose whether to work with it or against it. Working with it means checking dependencies before you plan a removal, not after the delete fails. Working against it means the pattern I see most often — someone tries to delete a table on a Friday, gets an error, deletes the obvious blocker, gets another error, and unpicks a chain of six components without a record of what they removed. Run Show Dependencies first, write the list down, then work the list from the leaves inward. The other place this matters is import failures: a missing-dependency error on import is almost always a solution content problem in dev, not an environment problem in test, and looking in the wrong place costs hours.

Configuration decisions

Whether a solution is self-contained or deliberately depends on a base solution, which changes whether export warnings are acceptable or a defect.
Whether to segment tables so a solution carries only changed assets, which reduces both unnecessary layers and unintended dependencies.
Whether ribbon and sitemap references use the $webresource: directive, which is the difference between tracked and untracked.
Install order for solutions with a base-and-extension relationship, since managed components can only depend on managed components.
What gets removed first when a component is being retired, worked out from the dependency list rather than by trial and error.

Gotchas

Missing-dependency on import is the classic symptom of segmenting a table that doesn't exist in the target. If a table has never been imported there, you must include all objects, not just the metadata.
Untracked web resource dependencies are the quiet ones. Your HTML page references a script file, the script isn't in the solution, nothing warns you, and the page breaks in production.
Export warnings can legitimately be ignored when a solution is designed to install over a base — which means people learn to ignore export warnings generally. That's how the real one gets missed.
Publishing is part of dependency removal, not an afterthought. Remove the lookup from the form and the dependency persists until the form is published.
Uninstalling a base solution while a dependent solution is still installed is blocked, so uninstall order is the reverse of install order and nobody documents it.

Consultant notes

Make Show Dependencies the first step in any deletion request, and capture the output as a change record. It's the difference between a controlled removal and an archaeology exercise.
Explain to clients that "won't delete" is the platform protecting them, not a bug. Otherwise someone finds a way around it and you inherit the inconsistency.
Solution import failures deserve a documented triage order: is the component missing from the solution, missing from the target, or the wrong package type. Three questions, most failures resolved.
Segment tables properly and half of these problems never appear. Include all objects for tables new to the target, metadata or selected assets for tables already there.

Worth another look if untracked web resource references ever start being tracked, or if the dependency viewer gains a bulk export.