Forum Discussion

fabricpribeiro's avatar
fabricpribeiro
Icon for Post Patron rankPost Patron
3 months ago
Solved

How to avoid people creating multiple times the same table in different workspaces

Dears,   We have a situation in Fabric where we have more than 6K workspaces.. Which seems to be an indicator that things are not properly governed. Hence we are starting a journey to govern it   ...
admin
governance
  • Dev_Dholakia's avatar
    Dev_Dholakia
    2 months ago

    Hi fabricpribeiro ,

     

    Thanks for the context — that helps.


    With a mix of item types and domains already in place, you're in a good spot. Domains let you delegate certification and duplicate-review to domain admins, which is usually where central governance stalls at scale.


    On Fabric APIs vs Purview — they solve different problems, not either/or:

    • Purview Unified Catalog = business-facing surface (glossary, data products, classifications, lineage across sources). Best for stewards and consumers.
    • Fabric Catalog Search + admin APIs = programmatic/operational surface. Query Fabric metadata directly (items, workspaces, domains, endorsement, owners, schemas) to build custom duplicate-detection jobs, dashboards, and Teams alerts.

    Purview for humans, Fabric APIs for machines. Purview scans are scheduled and great for the catalog view, but not built for real-time duplicate prevention. Fabric APIs let you run lightweight jobs that flag suspicious items as they appear.

    APIs worth looking at:

    Microsoft Fabric REST API documentation 
    full-tenant item enumeration 

    SImple Starting recipe: scanner API nightly → load into a governance Lakehouse → flag duplicate/near-duplicate table names outside certified workspaces → notify the domain steward. Cheap to build, high ROI at your scale.

    Hope That helps!

Parchitect's avatar
Parchitect
Icon for Solution Sage rankSolution Sage
3 months ago
This is not only a Fabric technical issue. It is a data governance and data architecture issue.

 

Since you already have a workspace onboarding process, I would extend that process with a required data discovery and architecture review step.

 

Before a team creates new tables, they should answer:
- Does this data already exist in OneLake Catalog or Purview?
- Is there already a certified/master data product for this entity?
- Is this table a new domain-specific table, or a duplicate of an enterprise entity such as Customer or Product?
- Should the team create a new table, or consume the existing one through a shortcut, shared Lakehouse/Warehouse, or shared semantic model?
- Who owns the data product and who is allowed to certify or modify it?

 

The architecture pattern I would use is:
Authoritative/master data workspace
→ Certified Customer/Product/Supplier tables
→ Reuse through OneLake shortcuts or shared semantic models
→ Domain/project workspaces consume trusted data instead of copying it

 

OneLake Catalog should be the first discovery point because it is designed to help users find, explore, use, and govern Fabric items across workspaces. Purview should complement this with business glossary, lineage, sensitivity, ownership, and data product governance. 

 

Shortcuts are also important because they allow teams to reuse existing data without creating unnecessary copies.

 

So the onboarding process should not only ask “why do you need a workspace?” 
It should also ask “what data do you plan to create, and does it already exist?”

 

That is how you avoid turning Fabric into another spaghetti architecture.