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

Hello fabricpribeiro,

This is a common challenge as Fabric adoption grows. In my opinion, endorsements alone won't prevent duplication - they only help users identify trusted assets.

A few practices that have worked well are:

1. Make discovery the first step

• Encourage teams to search the OneLake Catalog (and Purview where available) before creating new tables. The easier it is to discover existing assets, the more likely they are to be reused.

2. Define authoritative data products

• Identify core entities such as Customer, Product, Supplier, etc., and designate a single Certified or Master Data source for each. Project teams should consume these instead of recreating them.

3. Promote reuse through architecture

• Instead of copying tables into every workspace, encourage reuse via OneLake shortcuts, shared Lakehouses/Warehouses, or shared Semantic Models where appropriate.

4. Establish governance gates

• As part of the workspace provisioning process, require teams to verify whether an equivalent data asset already exists before creating a new one. This can be included in your workspace request checklist.

5. Monitor and review duplication

• Use Purview and Fabric metadata to periodically identify duplicate assets and work with project teams to consolidate them where possible.

Regarding your specific questions:

1. How can people know whether a table already exists?

Today, the OneLake Catalog is probably the best starting point for discovery within Fabric, with Purview complementing it through richer governance and lineage.

2. Can Fabric prevent duplicate table creation?

As far as I'm aware, there isn't currently a built-in policy that prevents users from creating a table simply because one with the same business meaning already exists elsewhere. This is primarily addressed through governance, discoverability, and reuse patterns rather than technical enforcement.

With an environment of 6,000+ workspaces and 17 million data assets, I'd focus on making trusted data products easy to find and reuse, while introducing governance processes that discourage unnecessary duplication.

Best regards,
Omkar Shinde
Microsoft Fabric Enthusiast | Power BI Consultant

💡 If you found this response helpful, please consider giving it a Kudos.
✅ If this resolves your question, please mark it as the Accepted Solution to help others in the community.

Hi fabricpribeiro ,

Honest answer at your scale: no single control stops duplicate tables. It has to be discovery + standards + light review.

Point everyone at the OneLake catalog as the mandatory first stop — search by name, schema, owner, badge, domain across all workspaces. Pair it with the Purview Unified Catalog for business glossary, data products, and lineage.

Fabric won't auto-block a CREATE TABLE because something similar exists elsewhere. Prevention comes from governance, not the engine — restricted write access on gold/master lakehouses, workspace templates, naming standards, and periodic duplication audits via admin APIs or Purview scans.

Practical pattern that actually reduces duplication:

• Gold/master workspaces for shared entities (Customer, Product) with write access locked to a small stewardship group. Others consume via OneLake shortcuts, not by re-creating tables.
• Endorsement badges (Promoted / Certified / Master data) for trust and search ranking — helpful, but signals only, not enforcement.
• Domains + naming standards so authoritative tables live in a known place with predictable names; delegate certification to domain admins.
• Purview data products for the business view — start with your top 10–20 entities even if the model isn't complete.
• Workspace request process (which you already do) plus a "does this already exist?" checklist referencing the catalog.
• Monitoring with the Catalog Search REST API or admin APIs to flag likely duplicates for stewards.

Short version: OneLake catalog + Purview for discovery, shortcuts to certified gold for reuse, a small steward group owning master entities. Badges and templates support this — they don't replace it.

Two quick clarifications:

Are the 17M assets mostly Lakehouse tables, or a mix (warehouses, semantic models, shortcuts)?
Do you already have Fabric domains defined, or is workspace-by-request your only organizing layer today?

If this got you what you needed, a Kudos and an Accepted Solution mark would be great — it helps others searching for the same thing find the answer quicker.

Hi fabricpribeiro ,

Could you please check the provided solution and let us know if you have any further questions.

Thanks!!

Hi fabricpribeiro ,

Could you review the suggestion provided above and let us know if you have any additional questions, we are happy to address. 

Thanks!!