Dependency Hell – What It Is, Why It Happens, and How Nevermore Stays Sane

So, there you are. You’ve built your solutions, wired up your apps, your flows are flowing, your plugins are plugin-ing… and then suddenly you try to delete a field.

Nope.

Power Platform looks at you like you’ve just tried to remove the foundations from a house, and spits out a message like:

“This component cannot be deleted because it is referenced by another component in a different solution.”

Welcome to Dependency Hell.

What Are Dependencies, Really?

In Power Platform, a dependency is any link between components—tables, fields, apps, flows, plugins, forms, views, connection references, even environment variables.

If one thing relies on another, that’s a dependency.

And they’re not just tracked in the same solution. Oh no. They’re tracked across solutions, even across layers. That’s where it gets messy.

The Nightmare Scenario

Here’s a tale from the early days of Nevermore’s ALM setup.

An app in Sales (Instance 1) was using a shared “Customer Profile” table from a core solution. No one documented it properly. Then someone in Dev removed a lookup field used by a model-driven app in Integration (Instance 5).

Test deployments failed. Pipelines halted. Confusion reigned. Tea went cold.

From that day forward, Nevermore adopted the golden rule:

“If it has a dependency, it goes in the same solution—or gets properly documented.”

Rule 1: Use Shared “Core” Solutions

Rather than letting every team build their own version of the same table or logic, Nevermore created a Core Layer:

• Core-Data
• Core-Plugins
• Core-Flows

These hold all the common components shared across apps. Anything that’s going to be used by multiple solutions must live here.

That way, when someone builds a new app, they reference the existing components rather than duplicating them.

Rule 2: Don’t Split a Form Across Solutions

This one trips up even seasoned folks. You’ve got a form for the Contact table. You modify it in two different solutions—say, once for Sales and once for Support.

Result? Form merge conflicts.

What you see on the form in Production might not match what you see in Pre-Prod. It depends on the solution layering order.

Nevermore’s fix: own each form in one place only, and use role-based forms if you need to show different versions.

More here: Solution Layering and Form Merging

Rule 3: Treat Plugins, Flows, and Environment Variables as First-Class Citizens

Dependencies aren’t just data-related. They include:

• A flow that uses a specific table
• A plugin referencing a field
• An environment variable tied to a flow or app
• A connection reference required by a Power Automate action

These must be included in your solution. Nevermore enforces a checklist before exporting:

• All flows must reference environment variables (not hard-coded values)
• Plugins must be compiled, tested, and stored in Core-Plugins
• Connection references are stored in a DeploymentResources solution
• Each dependency has an owner

Rule 4: Use “Show Dependencies” Before Deleting Anything

You might think a field is unused. Power Platform knows better.

Before deleting anything, Nevermore runs a dependency check from the solution explorer:

1. Open the solution
2. Select the component
3. Click “Show Dependencies”
4. Prepare to be surprised

If it’s used anywhere (even in a hidden flow someone forgot about), the platform will block the deletion. Good. That’s your chance to investigate before disaster strikes.

Rule 5: Clean Up Layers Regularly

Even with the best planning, solution layering can still get messy. Nevermore schedules quarterly audits using the Solution Layer Viewer from XrmToolBox, checking for:

• Orphaned layers
• Conflicting unmanaged changes
• Unused fields or components
• Patch solutions left hanging

Think of it as spring cleaning for your Dataverse.

TL;DR – Respect the Web

Dependencies aren’t the enemy. They’re a fact of life in any serious Power Platform project.

But if you manage them deliberately:

• Centralise shared logic in core solutions
• Don’t cross the streams with forms and views
• Include everything your app needs inside its solution
• Use environment variables, not hard-coded values
• And never, ever, delete something without checking dependencies first

Next Up: Blog 9 – Patching and Upgrades (or, How Not to Ruin Everything with One Click)

In Blog 9, we’ll explore how Nevermore handles solution updates—patching vs upgrading, versioning best practices, and how to avoid the dreaded “everything’s gone red in Prod” moment.

Until then, be kind to your components. They’ve got trust issues now.