--- title: "What happens when you unlink Dynamics 365 from Microsoft Fabric?" canonical_url: "https://cognilium.ai/blogs/what-happens-when-you-unlink-fabric" slug: "what-happens-when-you-unlink-fabric" section: "blogs" date_published: "2026-09-14" date_modified: "2026-09-14" word_count: 846 reading_time_minutes: 4 author: "Mudassir Marwat" author_identifier: "0009-0008-1927-2598" person_same_as: - "https://www.linkedin.com/in/mudassir-marwat/" - "https://orcid.org/0009-0008-1927-2598" - "https://github.com/mudassirmarwat" - "https://medium.com/@mudassir-marwat" - "https://www.youtube.com/@mudassir-marwat" - "https://dev.to/mudassirmarwat" - "https://hashnode.com/@mudassirmarwat" - "https://huggingface.co/mudassirmarwat" - "https://bsky.app/profile/mudassir-marwat.bsky.social" - "https://substack.com/@mudassirmarwat" - "https://topmate.io/mudassirmarwat" - "https://fueler.io/mudassirmarwat" - "https://www.instagram.com/mudassirmarwat/" - "https://www.facebook.com/mudassir.marwat" - "https://www.reddit.com/user/mudassirmarwat/" - "https://www.f6s.com/member/mudassir-marwat" - "https://cognilium.ai/founder" entities: [] related: - "https://cognilium.ai/blogs/dynamics-365-optimizer-write-path" - "https://cognilium.ai/blogs/odata-throughput-dynamics-365" - "https://cognilium.ai/blogs/dynamics-365-service-protection-limits" --- # What happens when you unlink Dynamics 365 from Microsoft Fabric? Unlinking deletes the Fabric lakehouse, and everything built on it goes too. What to check before anyone treats it as a reversible setting. ## Key takeaways - Unlinking Dynamics 365 from Microsoft Fabric deletes the Fabric lakehouse rather than detaching it. - The source data remains in Dataverse; the Fabric-side lakehouse, SQL analytics endpoint and default semantic model do not. - Notebooks, pipelines, reports and cross-workspace shortcuts that reference the lakehouse all break. - Microsoft says not to depend on the generated lakehouse name, which is unstable; reference by workspace and lakehouse ID. - Relinking needs the original prerequisites to still hold, and the initial resync can take an hour or more. **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". ## Frequently asked questions ### Does unlinking delete my Dynamics 365 data? No. The source data stays in Dataverse and in the ERP. What is deleted is the Fabric lakehouse, which was an expression of the link rather than an independent copy you owned. ### Can I keep the lakehouse and just stop the sync? Not through unlinking, which removes the lakehouse. If the goal is to stop the data moving while keeping what has been built, the question to answer first is whether what you need to keep is the lakehouse itself or the modelling on top of it. The second can be preserved independently; the first cannot. ### How long does relinking take? Plan on the initial sync and Delta/Parquet conversion running up to an hour, and longer for large tables. Steady-state refresh then runs on a similar cycle. Everything reading the lakehouse is unavailable until the first pass completes. ### Will the lakehouse have the same name after relinking? Do not rely on it. Microsoft explicitly says not to take a dependency on the generated name. Anything you rebuild should reference workspace and lakehouse by ID. ### Is there a safer alternative if I need the data somewhere I control? Azure Synapse Link for Dataverse writes Delta-Parquet into an ADLS Gen2 storage account you provision, so the storage is yours and stopping the profile does not delete it. That is a different trade, with a storage account to manage, and it is the right one when ownership of the destination matters more than the operational saving. --- Canonical HTML: https://cognilium.ai/blogs/what-happens-when-you-unlink-fabric