Unable to restrict table-level SELECT access in Fabric Warehouse -Workspace VW overrides SQL perms

[Ayush05-gateway]

Hi community,

I am trying to implement table-level access control for an AD group on a Fabric Warehouse and running into a conflict between workspace-level and SQL-level permissions. Looking for guidance on the recommended approach.

**Setup**
- Microsoft Fabric Warehouse (GW_DWH_Prod)
- AD group: Data-Readers
- Goal: Grant SELECT on specific tables only within 2 of the schemas out of 10 schemas

**What I did**
1. Shared warehouse item with the AD group with ReadData permission only (Read, ReadData)
2. Granted CONNECT and table-level SELECT via T-SQL:
```sql
GRANT CONNECT TO [Data-Readers];
GRANT SELECT ON OBJECT::GWDWH.Customer TO [Data-Readers];
GRANT SELECT ON OBJECT::GWODS.Affiliation_Dim TO [Data-Readers];
```

**Problem 1 — Authentication fails without Workspace Viewer**
With item-level ReadData only and no Workspace role, users get authentication failed when connecting via SQL endpoint using SSMA. Adding Workspace Viewer fixes the connectivity issue.

**Problem 2 — Workspace Viewer exposes all tables**
Once Workspace Viewer is added, users can see ALL tables across GWDWH and GWODS schemas — not just the ones explicitly granted. I verified via sys.database_permissions that no schema-level SELECT grants exist for this group, and the user is not part of any other AD group with broader permissions. db_datareader role is also not assigned.

**What I confirmed**
- DENY on other schemas works correctly — users cannot see tables on those schemas
- sys.database_permissions only shows CONNECT at DATABASE level and SELECT on specific tables for this group
- No schema-level grants exist for this group
- Workspace Viewer appears to be implicitly granting ReadData/SELECT across all schemas at the platform level, bypassing SQL permissions

**Question**
Is there a supported way to:
1. Allow SQL endpoint connectivity without Workspace Viewer?
2. OR restrict table visibility when Workspace Viewer is assigned, - like DENY on schema and explicit table GRANTs?

Is this a known platform limitation? Any recommended workaround?

Thanks in advance.

Ayush Aggarwal

[Ayush05-gateway]

hi @v-ssriganesh  no, not with the user group . I am checking with inidividual users and testings. I'll update next week if it works or nt.

[v-ssriganesh]

Hello @Ayush05-gateway,
Thank you for the update.

[v-ssriganesh]

Hello @Ayush05-gateway,

Hope everything’s going great with you. Just checking, the issue been resolved or are you still running into problems? Sharing an update can really help others facing the same thing.

Thank you.

[v-ssriganesh]

Hi @Ayush05-gateway,
Thank you for posting your query in the Microsoft Fabric Community Forum.

The official documentation states that the Workspace Viewer role automatically grants CONNECT and ReadData permissions for all Warehouses and SQL endpoints in the workspace. Because of this, assigning Workspace Viewer provides broad read access and can expose all tables/views, even when granular T-SQL permissions are configured.

For fine-grained access control, Microsoft recommends using Warehouse item-level Read permission together with granular T-SQL GRANT/DENY permissions instead of Workspace Viewer access. Users should be able to connect with minimum item-level Read permission plus explicit SQL permissions such as GRANT CONNECT and table-level GRANT SELECT. If connectivity still fails without Workspace Viewer, this may indicate a current platform limitation or tool/client-specific behavior that may require a support case for further investigation.

For your reference:

• Workspace roles in Fabric Data Warehouse
• SQL granular permissions in Microsoft Fabric
• Secure your Fabric Data Warehouse

Best regards,
Ganesh Singamshetty