Forum Discussion

Alaahady's avatar
Alaahady
Icon for Advocate II rankAdvocate II
1 day ago

Best practice for sharing a semantic model across multiple Fabric workspaces without duplicating it

Hi Fabric Community,

I’m looking for guidance on the recommended architecture for sharing centralized semantic models across multiple Microsoft Fabric workspaces.

My current architecture is:

  • DEV Workspace
    • Lakehouse and centralized data
    • Data pipelines
    • Notebooks
    • Semantic models
    • Accessible only to developers/admins
  • Sales Workspace
    • Sales reports and Fabric App
    • Accessible only to Sales users
  • Production Workspace
    • Production reports and Fabric App
    • Accessible only to Production users
  • Speciality Workspace
    • Speciality reports and Fabric App
    • Accessible only to Speciality users
  • Leadership Workspace
    • Leadership reports and Fabric App
    • Accessible only to Leadership users

The reports in the departmental workspaces are connected to semantic models located in the DEV workspace.

The problem is that users can access their department's Fabric App/workspace, but they cannot open the reports because they don't have access to the semantic models in the DEV workspace.

My goal is to keep the semantic models centralized in DEV as a single source of truth, while keeping the DEV workspace itself restricted to developers.

Questions:

  1. Do end users need access to the DEV workspace to consume reports connected to a semantic model located there without grant users permission on semantic model?
  2. Is Build permission required for users who are only consuming reports through a Fabric App, or is Read sufficient?
  3. What is the recommended architecture for this scenario?
  4. Should I keep one centralized semantic model, or duplicate/deploy the semantic model into each departmental workspace?
  5. What is Microsoft's recommended approach for maintaining departmental security while avoiding duplicated semantic models?

Ideally, I would like the architecture to remain:

Central Lakehouse → Central Semantic Models → Department Workspaces/Reports → Department Fabric Apps

while users only receive access to the data and reports relevant to their department.

Thanks in advance for any recommendations or examples of how others have implemented this.

 

data engineering
lakehouse

4 Replies

  • v-sathmakuri's avatar
    v-sathmakuri
    Icon for Community Support rankCommunity Support
    16 hours ago

    Hi Alaahady​ ,

    Thank you for reaching out to fabric community.

    • Keep one centralized semantic model in the DEV workspace, avoid duplication.
    • Grant departmental users Read permission on the semantic model without giving them access to the DEV workspace.
    • Build permission is not required for users who only consume existing reports.
    • Publish reports through departmental Fabric Apps and configure appropriate App audiences.
    • Implement RLS/OLS to restrict data access by department.
    • Test with departmental user accounts to verify report access and data security.

    Thanks!!

    • Alaahady's avatar
      Alaahady
      Icon for Advocate II rankAdvocate II
      10 hours ago

      Hi v-sathmakuri​ 

      Thank you for your comprehensive respond. I agreed with most of your points

      I have 2 questions here:

      1. How to Grant departmental users Read permission on the semantic model without giving them access to the DEV workspace.
      2. Is there another option, I have thousands of users and granting access to more than 120 semantic model is a full-time job and I'm afraid of losing control and impact governance 
      • Alaahady's avatar
        Alaahady
        Icon for Advocate II rankAdvocate II
        10 hours ago

        Hi v-sathmakuri​ 

        Thank you for your comprehensive respond. I agreed with most of your points

        I have 2 questions here:

        1. How to Grant departmental users Read permission on the semantic model without giving them access to the DEV workspace.

        2. Is there another option, I have thousands of users and granting access to more than 120 semantic model is a full-time job and I'm afraid of losing control and impact governance 

  • jubinsoni's avatar
    jubinsoni
    Icon for Skilled Sharer rankSkilled Sharer
    3 hours ago

    Hi Alaahady​,

    The permissions advice above is the right core. One structural change I would add: avoid having production reports depend on models in the DEV workspace. Every edit a developer makes there is instantly live for all four departments. A layout that keeps one copy of each model but separates environments:

    DEV  Data       (lakehouse, pipelines, notebooks)        developers only
DEV  Models     (semantic models under development)     developers only
        | deployment pipeline / Git
PROD Data       (lakehouse)                              no business users
PROD Models     (shared, certified semantic models)      no business users
        | Read permission on each model (per department SG)
Sales / Production / Speciality / Leadership workspaces
   thin reports + one app each                           department SG via app audience

    Department users then get: app audience in their own workspace + Read on the shared model (no workspace role in PROD Models). If the models are Direct Lake, either use a fixed-identity connection or also grant ReadData on the PROD lakehouse, otherwise reports render with permission errors.

    For "only relevant data", a single dynamic RLS role scales better than one role per department:

    -- table UserDepartment(UserEmail, Department), maintained from HR / Entra groups
-- RLS filter on the Department dimension:
'Department'[Department]
    IN CALCULATETABLE (
        VALUES ( UserDepartment[Department] ),
        UserDepartment[UserEmail] = USERPRINCIPALNAME ()
    )

    Leadership can be handled with a second role whose filter is simply TRUE().

    So my overall approach would be:

    Separate DEV and PROD for data and models (deploy via pipeline/Git)
-> One shared, certified model per subject in PROD Models
-> Department SG: Read on model + app audience, no PROD workspace role
-> Dynamic RLS via a user-department table; Leadership role = TRUE()

    AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.