Fixing “Import of app module(s) failed: Expected non-empty Guid” in Dynamics 365

Recently, I ran into one of those Dynamics 365 solution import errors that looks simple but can easily burn hours or even days of investigation.

The error was:

Import of app module(s) failed: Expected non-empty Guid

No table name.
No component reference.
No clear indication of what exactly was broken.

In this post, I want to share what actually caused this issue, how I investigated it as a Dynamics 365 CRM developer, what Microsoft support finally confirmed and the exact fix that resolved it. If you work with model-driven apps and modern command bar buttons, this will likely save you a lot of time.

The project context

This was a standard enterprise Dynamics 365 / Dataverse setup:

Development → Test/QA → Production
Managed solutions for deployment
A model-driven app as the primary deliverable

The app itself was not new. It had already been deployed multiple times without any problems.
The recent changes were mostly UI-related, including:

Command bar buttons created using the modern command designer
Power Fx formulas controlling button visibility and actions
Removal of a few entities from the app navigation
Small data model changes like precision updates on some columns

Nothing looked risky. Everything worked perfectly in the development environment.

When the problem started

The issue appeared only when importing the managed solution into the target environment.

The import failed with:

Error Code: 80040203
Message:
Import of app module(s) failed: Expected non-empty Guid

The important detail here is “app module(s)”.
This immediately ruled out plugins, flows, and most data model issues.

I tried the obvious fixes first:

Re-exported the solution
Verified dependencies
Rechecked entity availability
Compared column changes across environments

Everything looked clean. The error still persisted.

Why this error is so misleading

The phrase “Expected non-empty Guid” is extremely generic.
It doesn’t tell you:

Which component
Which app
Which layer
Or even which entity is involved

At this point, it was clear that something inside the app metadata itself was broken—but not in a way that was visible from the UI.

Focusing on command bar customizations

The only major area touched recently was the command bar.

During development:

We created multiple custom buttons
Used Power Fx for enable rules and visibility
Tested different variations
Removed or hid some buttons later when they were no longer needed

So I started reviewing command bar configurations entity by entity.

That’s when I noticed something odd.

One button still existed in the solution layers, but:

It wasn’t visible in the app
It wasn’t associated with any app
It looked like a leftover from earlier testing

Visually, it felt “deleted.”
Technically, it wasn’t.

This raised a strong suspicion:
the app module still had a reference to this button internally, but the button itself no longer had a valid identity during import.

Microsoft support confirmation

To be sure, I raised a Microsoft support ticket.

After reviewing internal logs and diagnostics (which we don’t have access to), support confirmed the root cause:

A command bar button orphan layer existed
The button had been removed from the UI but not fully removed from metadata
The app module still referenced that button
During import, Dataverse expected a valid GUID—but received an empty one

That was the source of the error.

Once this orphan layer was removed, the issue disappeared.

The actual fix that worked and you can also try it might work

The resolution was simple once the cause was known:

Opened the command bar buttons in each entity in the source environment
Identified the leftover button that:
- Was not associated with any app
- Was clearly a test or unused customization
Deleted the button completely (not just hiding it)
Published all customizations
Exported a fresh managed solution
Imported it again into the target environment

What this taught me

This issue taught me a few important lessons about modern command bar customization in Dynamics 365:

Deleting buttons is not always clean

Removing a button from the designer does not always remove every underlying customization layer. Orphan layers can remain silently.

Command bars can break app module imports

Even though command bars feel like a UI feature, they are deeply tied to app module metadata. A broken reference here can block the entire deployment.

Microsoft logs matter

Errors like this cannot always be solved from the UI alone. Microsoft support logs are often the only way to confirm orphan layers.