What happens when you unlink Dynamics 365 from Microsoft Fabric?

Unlinking deletes the Fabric lakehouse. It does not detach the link and leave the data sitting where it was. The lakehouse goes, and anything that depended on it goes with it.

That is the whole answer, and it is worth stating plainly because the word "unlink" implies something reversible and the operation is not.

Why the wording misleads

Every other integration in this area can be turned off and turned back on. A Synapse Link profile can be paused. A dual-write map can be stopped. An OData integration is a client that you can simply stop calling. Nothing is destroyed in any of those cases, so the pattern people carry into Fabric is that a link is a switch.

Link to Microsoft Fabric is not a switch, because the lakehouse it created is not somewhere your data was copied to. Dataverse holds the managed OneLake store, and Fabric holds shortcuts into it. Remove the relationship and the Fabric-side object that existed only to express that relationship is removed too.

The data itself is still in Dataverse. The lakehouse is not.

What goes with it

The lakehouse is rarely the only thing that has been built. By the time anyone considers unlinking, there is usually a layer on top:

• The SQL analytics endpoint that Fabric provisioned alongside the lakehouse.
• The default Power BI semantic model, and any report bound to it.
• Notebooks, pipelines and dataflows that reference the lakehouse tables.
• Downstream shortcuts from other workspaces pointing at it.
• Anything parsing the lakehouse name, which brings its own problem.

That last one is worth a separate warning. Microsoft states explicitly that you should not take a dependency on the generated lakehouse name. It carries environment, profile and workspace segments and is not stable. A pipeline that resolves the lakehouse by display name is already fragile before anyone unlinks anything; reference workspace and lakehouse by ID instead. A large share of the example pipelines in circulation do the opposite.

When unlinking is still the right call

It often is. Environments get rebuilt, a proof of concept in the wrong workspace needs moving, a profile was configured against the wrong Fabric capacity, or the CSV-format history of an older Synapse Link profile means it cannot be linked to Fabric at all and a clean start is simpler.

The point is not to avoid the operation. It is to treat it as a rebuild rather than a toggle, and to know what has to be recreated before you begin rather than discovering it from a broken report.

What to check first

List what references the lakehouse. Notebooks, pipelines, semantic models, and shortcuts from other workspaces. This is the list you will have to recreate, and it is always longer than expected.

Find anything that resolves by name. If it exists, fix it now regardless of whether you unlink, because the name is unstable on its own terms.

Export the modelling, not the data. The data comes back on the next sync. The semantic model definitions, measures and relationships do not, unless someone saved them.

Confirm the re-link prerequisites still hold. Relinking needs the same conditions the first link needed: System Administrator in the Power Platform environment, Power BI workspace admin, and Power BI Premium or Fabric capacity in the same Azure geography as the Dataverse environment. If any of those changed since the original setup, the rebuild stalls at a permissions error rather than at the point you planned for.

Budget the resync time. The initial conversion to Delta/Parquet runs up to an hour and longer for large tables. That is downtime for everything reading the lakehouse, not a background task.

The general lesson

Managed services remove work by owning objects on your behalf, and the objects they own are the ones they can also remove. That is the trade, and it is usually a good one. The failure mode is assuming an object you can see in your own workspace is therefore yours to keep.

Before anyone runs an operation on a managed integration, the useful question is not "can I undo this" but "what does this service own, and what does it do with what it owns when the relationship ends".