Fabric Workload Development Kit - Clarification Needed on Setup and Usages

[Ashwath_Bala_S]

Hi Everyone,

I have a few questions related to "Fabric Workload Development Kit", which I would like to get it clarified.

Following are my questions:

1. Is there full documentation convert the existing Power BI app to Fabric Workload Kit? 

2. What are the prerequisites for starting with Fabric Workload Development Kit (WDK)?

3. Is there a starter template for WDK development?

4. Can we get a high-level architecture diagram for how WDK integrates with Fabric?

5. What all expertise needed for "Workload Development Kit"  development? 

6. Figma Fabric UI Kit doesn't have enough elements, can we use Fluent UI instead totally?

7. How can we embed Power BI visuals into our custom workload app using WDK?

8. Are there limitations in terms of embedding visuals vs full reports vs entire application of Power BI?

Thanks in advance!

Regards,

Ashwath

[Teddyb · Accepted solution]

Hi @Ashwath_Bala_S, thanks for the interest and would love if you can also share whether you are planning to release it as a public workload or for organizational use. 

1. Power BI App to Fabric Workload Kit Conversion

There is no direct "conversion" tool to migrate existing Power BI apps to Fabric workloads. The WDK is designed for building custom workloads that integrate with Fabric, not for converting Power BI apps.

However, you can:

• Reference your Power BI app's functionality and re-implement key features within a WDK shell
• Use the Microsoft Fabric Workload Development Kit overview - Microsoft Fabric | Microsoft Learn to build workloads that integrate with Fabric
• Leverage Power BI embedding capabilities within your custom workload (see question 7)

2. Prerequisites for Fabric Workload Development Kit

Technical Requirements:

• Microsoft Fabric subscription with F or P SKU capacity (trial capacities supported)
• Admin permissions on workspace to register workloads
• Tenant settings enabled:
  • "Workspace admins can develop partner workloads" (Admin portal > Tenant settings > Additional workloads)
  • "Fabric Developer Mode" (Settings > Developer settings)

Development Tools:

• Git - Version control
• Node.js (with npm version 9+)
• Visual Studio 2022 or Visual Studio Code with C# Dev Kit
• ASP.NET Core Runtime 6.0 and .NET 6.0 Runtime
• Webpack and Webpack CLI
• DevGateway utility (downloaded from Microsoft Download Center)

Azure Services:

• Microsoft Entra ID app registration
• Azure Storage consent (requires Global admin if not installed)

3. Starter Template for WDK Development

Yes! Microsoft provides a comprehensive starter template:

Microsoft Fabric Workload Development Sample

Features:

• Complete frontend (React + TypeScript) and backend (C# ASP.NET Core) implementation
• Sample calculator workload that demonstrates lakehouse integration
• Quick start guide with step-by-step setup instructions
• Demonstrates key WDK capabilities: CRUD operations, job management, authentication, UI components

Getting Started:

git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git
cd Microsoft-Fabric-workload-development-sample
# Follow the quickstart guide in documentation

4. High-Level Architecture Diagram

The WDK architecture consists of several key components:

Core Components:

• Frontend (React): Runs in sandboxed iframe within Fabric portal
• Backend (C# ASP.NET Core): Handles data processing, metadata storage, CRUD operations
• DevGateway: Manages local development communication via Azure Relay
• Workload Client SDK (@ms-fabric/workload-client): Provides APIs for Fabric integration

Integration Points:

• Microsoft Entra ID: Authentication and authorization
• OneLake: Data storage and management
• Fabric APIs: Item lifecycle, monitoring, notifications

Deployment Modes:

• Development Mode: Local machine with DevGateway
• Cloud Mode: Hosted services with direct HTTPS endpoints

5. Required Expertise for WDK Development

Frontend Development:

• React and TypeScript (primary framework)
• Fluent UI components and design system
• Webpack configuration and bundling

Backend Development:

• RESTful API design and implementation
• Microsoft Entra ID authentication flows
• Azure services integration (Storage, Relay)

Data & Analytics:

• OneLake integration patterns
• Lakehouse architecture understanding
• Data processing and ETL concepts

DevOps & Deployment:

• Azure Marketplace publishing
• NuGet packaging
• CI/CD pipelines
• Workload certification requirements

6. Figma Fabric UI Kit vs Fluent UI

Yes, you can use Fluent UI exclusively!

Key Points:

• The WDK sample is built on top of Fluent UI and designed for React
• Fluent UI provides visual consistency with Fabric's look and feel
• The official documentation states: "UX workloads use Fluent UI controls for visual consistency with Fabric and for ease of development"
• Fabric UX System is based on Microsoft's Fluent 2 Design System

Recommended Approach:

• Use Fluent UI React components directly
• Reference the Fabric UX System for design tokens, spacing, and color palette

7. Embedding Power BI Visuals in Custom Workload

Power BI embedding in WDK is possible but requires careful architecture:

Approach:

• Use Power BI Embedded APIs within your workload's iframe
• Implement Power BI JavaScript SDK in your React frontend
• Handle authentication tokens through your workload's Entra ID app
• Leverage OneLake integration for data consistency

Implementation Pattern:

// Example integration pattern
import { PowerBIEmbed } from 'powerbi-client-react';

// Within your workload component
<PowerBIEmbed
  embedConfig={{
    type: 'visual',
    id: 'visualId',
    embedUrl: 'embedUrl',
    accessToken: 'accessToken'
  }}
/>

8. Power BI Embedding Limitations

Embedding Capabilities:

• WDK is based on embedding an application iframe in Fabric, which can be a Power BI report or a full blown application.

Key Limitations:

• Authentication complexity: Must handle token management between workload and Power BI
• Iframe restrictions: Sandboxed environment may limit some Power BI features
• Data governance: Ensure proper security boundaries between workload and Power BI data

Best Practices:

• Design for integration: Rather than full embedding, consider building native Fabric experiences
• Leverage OneLake: Use shared data layer for consistency
• Authentication flow: Implement proper On-Behalf-Of (OBO) token flows

Additional Resources:

• Official Documentation
• Workload API Reference
• Frontend SDK Reference
• Sample Repository Issues
• Fabric UX System

The WDK provides a robust foundation for building custom analytics experiences within Fabric. Start with the sample repository and leverage the comprehensive documentation to build your workload step by step.

[Anonymous]

Hi @Ashwath_Bala_S,

Thanks for reaching out to the Microsoft fabric community forum and for raising this important topic. You are absolutely right that Power BI doesn't natively support page-level security, and your current workaround using RLS, bookmarks, and conditional navigation is a common but imperfect solution. Here’s a refined approach that might help you achieve all three of your goals:

There isn’t a one-click "conversion" tool to migrate a Power BI app into a WDK-based app, since WDK is geared towards building custom workloads rather than just extending Power BI. However, the API reference documentation for Windows Driver Kit (WDK) - Windows drivers | Microsoft Learn walks you through how to create apps that integrate tightly with the Fabric platform, and you can reference your Power BI app’s functionality while re-implementing key elements inside a WDK shell.

* If you want an Improved workaround for Page-Level Security in Power BI, use a Page Access Table with RLS Create a disconnected table (e.g., PageAccess) with two columns:

• UserEmail – email addresses of users.
• PageName – names of pages they should access.

Apply RLS using USERPRINCIPALNAME() to filter this table

[UserEmail] = USERPRINCIPALNAME()

* To create navigation buttons for each pPage Instead of hiding pages, keep all pages visible but control access using buttons. Use a measure like:

Nav_PageX = IF("PageX" IN VALUES(PageAccess[PageName]), "PageX", BLANK())

* Use conditional formatting for Button visibility based on the user’s access. If the user doesn’t have access, the button can either be hidden or redirect to a “Permission Denied” page.

4. Keep all pages visible and do not hide pages in the report. Instead, rely on navigation buttons and RLS to control access. This ensures users see all tabs but can only interact with pages they’re authorized for.

If I misunderstand your needs or you still have problems on it, please feel free to let us know.  

Best Regards,
Hammad.

[Anonymous]

Hi @Ashwath_Bala_S,

As we haven’t heard back from you, so just following up to our previous message. I'd like to confirm if you've successfully resolved this issue or if you need further help.

If yes, you are welcome to share your workaround and mark it as a solution so that other users can benefit as well.

And if you're still looking for guidance, feel free to give us an update, we’re here for you.

Best Regards,

Hammad.