User Data functions to implement a backed for an industry solution

[pmscorca]

Hi,

I'd like to know if user data functions represent a good and valid feature in order to implement an industry solution (for many customers), safeguarding the intellectual property.

Any suggests to me, please? Thanks

[tayloramy · Accepted solution]

Hi @pmscorca, 

If you want to safeguard the business logic, then a custom workload is what you are looking for. 

Once a data function is deployed to a tenant, users in that tenant will be able to access them and view the logic. 

[v-prasare]

Hi pmscorca,

this is a very valid concern when thinking about protecting your ingestion and transformation logic.

A custom workload helps safeguard your logic by acting as a controlled, managed layer rather than exposing the implementation directly inside the tenant. Instead of users accessing or inspecting the underlying code (as can happen with user data functions), they only interact with the workload through defined interfaces, such as APIs or UI elements. This means the ingestion and transformation logic is effectively encapsulated and executed within the workload runtime, making it much harder for end users to view or reverse-engineer your intellectual property. In practice, it behaves more like a black-box service where you fully control what is exposed and what remains hidden.

For Fabric users, this works well because the workload is integrated into the Fabric environment and can be consumed with proper permissions and access controls. However, if a customer does not have Fabric, then they won’t be able to directly use the workload since it is a Fabric-native capability. In such cases, you would need to consider exposing your solution through an external layer, such as an API hosted in Azure or a SaaS-style application, so that customers can still consume the functionality without needing Fabric.

Overall, if protecting your ingestion and transformation logic is a priority in a multi-customer scenario, a custom workload (or an external service layer) is generally a better fit than relying only on user data functions.

Thanks,

prashanth

[pmscorca]

Hi, implementing a template app instead of a workload, with non-Fabric users in mind?

Thanks

[v-prasare · Accepted solution]

Hi @pmscorca ,

A template app can be considered for distributing your solution to non‑Fabric users, but it doesn’t replace a workload from an architecture or IP‑protection perspective.

According to Microsoft documentation please refer below, Power BI template apps are primarily designed to package and deploy prebuilt datasets, reports, and dashboards to any Power BI customer and allow users to install and customize them within their own tenant.

While this makes them effective for solution distribution and reuse, customers can still install, modify, and access the underlying artifacts, which means they don’t inherently protect your ingestion or transformation logic. In contrast, Fabric custom workloads are designed as extensible applications embedded in the platform, where your logic runs within your controlled service layer and integrates into Fabric via secure APIs and authentication.

Therefore, template apps are best suited for delivery and onboarding, whereas protecting backend logic in multi‑customer scenarios typically requires a workload or an external service layer.

Create template apps in Power BI - Power BI | Microsoft Learn

Microsoft Fabric Extensibility Toolkit - Microsoft Fabric | Microsoft Learn

[tayloramy · Accepted solution]

Hi @pmscorca, 

If you want to safeguard the business logic, then a custom workload is what you are looking for. 

Once a data function is deployed to a tenant, users in that tenant will be able to access them and view the logic. 

[pmscorca]

Hi, the customer users haven't see the ingestion and transformation logic.

How does a workload safeguard the ingestion and transformation logic? It is possible to use a workload as a Fabric user, but what happens if a customer doesn't have Fabric?
Thanks

[deborshi_nag]

Hello @pmscorca 

I would say Fabric Data Functions are a useful foundation, offering a serverless environment to centralize business logic, making them suitable for scaling industry solutions. They provide execution-level access without exposing the code, which is important when creating multi-customer solutions. However, when designing for multiple customers, it’s important to consider access control, authentication, and data segregation. This may mean setting up separate workspaces, identities, or function instances for each customer to prevent cross-tenant risks.

In summary, this is a practical feature, but it needs to be paired with the right architecture and permission model!