Architecture Guidance: Offer Type (AMA vs. SaaS) and Fabric Notebook Packaging

Golla Manish 0 Reputation points
2026-09-14T07:06:43.4133333+00:00

Hello Team, we are preparing to publish a new product to the Azure Marketplace and need your guidance on the correct Offer Type and supported deployment patterns for the architecture detailed below:

We have analytics on azure specialization, data and AI, Digital and App Innovation, Infrastructure partner designations.

Our technical team building products to be listed on market place, however have come across the following :

Offer type

Given that our compute and data will run entirely inside the customer's own Azure subscription (not hosted by us), should we list this as a SaaS offer or an Azure Managed Application (customer-managed) offer?

Is deploying a Container App into the customer's subscription via a Managed Application template — which then calls the Fabric REST API using the customer's own service principal — a pattern Microsoft has seen before or recommends?

Is there a supported way to have our Container App (running in the customer's Azure subscription) publish or refresh a Report/Semantic Model directly into the customer's Fabric workspace using their own service principal, instead of hosting a separate dashboard ourselves — and if so, is this a recommended pattern, or are there limitations we should know about?

Deploying Fabric Notebooks as an Azure Marketplace product

What are the supported paths for distributing Fabric notebooks (and associated pipelines/logic) as an Azure Marketplace offer?

Can this be achieved using Fabric Workloads? If so, what does that packaging and deployment flow look like, and what are the extensibility/API surface constraints on a Workload today?

Alternatively, can this be achieved via a Power BI / Fabric app (app template distribution)? If so, how does notebook logic factor into that, given Power BI apps are typically report/dataset-centric?

Between the two (Workload vs. Power BI/Fabric app), is one the recommended/supported approach for our scenario (transformation logic in notebooks, run inside the customer's Fabric capacity)? Are there limitations (certification requirements, capacity dependencies, tenant admin settings) we should plan around for either path?

Azure | Azure ISV (Independent Software Vendor)
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Muhammad Bilal Khan 80 Reputation points
    2026-09-14T07:29:33.2066667+00:00

    Hello @Golla Manish

    For the architecture you've described, I would separate the Azure Marketplace offer type question from the Fabric distribution question.

    Azure Marketplace offer

    Because your Container App and other compute/resources are intended to run inside the customer's Azure subscription, an Azure Application / Managed Application is generally a better fit than SaaS.

    Microsoft describes SaaS offers as software that runs in the publisher's tenant, while Managed Applications are deployed into the customer's subscription. Managed Applications can contain resources such as containers, networking, storage, etc.

    So your pattern:

    Marketplace → Managed Application → Customer subscription → Container App → Customer Fabric workspace

    is conceptually aligned with the Marketplace deployment model.

    One important design decision is whether the managed application is customer-managed or publisher-managed, because that changes what access the publisher has to the deployed resource group.

    Container App → Fabric

    Yes, a Container App deployed in the customer's subscription can call Fabric APIs using an appropriate Microsoft Entra identity/service principal, provided the required Fabric permissions and workspace roles are configured.

    For example, the Fabric REST API for creating a report explicitly supports service principals and managed identities, provided the identity has the required workspace permissions.

    I would therefore avoid hosting a separate dashboard purely because the application lives in Azure. The Container App can act as the provisioning/orchestration layer and publish/update Fabric artifacts in the customer's workspace.

    The customer will still need to provide/authorize the required identity and Fabric workspace/capacity configuration.

    Fabric notebooks in Marketplace

    This is where I would not position a Fabric Workload as simply a Marketplace package for your notebooks.

    A Fabric Workload is a web application that integrates into the Fabric portal. Fabric hosts the workload experience in an iframe, and the workload can integrate with Fabric through its manifest and host APIs.

    Microsoft does provide a mechanism for publishing and managing workloads, but this is fundamentally an extensibility model for a Fabric-native application experience, not a general-purpose Marketplace installer for “here are some notebooks + pipelines.”

    So I'd think about the two options this way:

    Fabric Workload → Best when you're building a product experience that should appear natively inside Fabric and interact with Fabric items/workspaces.

    Fabric/Power BI app or template → Better for distributing a predefined analytics experience, reports, semantic models and related content, but it isn't a natural packaging mechanism for arbitrary notebook-based application logic.

    There is also a distinction between Fabric app templates and Marketplace offers. Fabric's current template tooling is intended to scaffold/distribute Fabric app projects; it shouldn't be confused with Marketplace packaging for a complete notebook-based product.

    What I'd recommend for your scenario

    I'd consider this architecture:

    Azure Marketplace Managed Application → deploy Container App + required Azure resources into customer subscription → customer authorizes Entra identity → Container App calls Fabric REST APIs → provision/configure customer's Fabric workspace → create/populate Fabric artifacts → notebooks/pipelines execute against customer's Fabric capacity

    Then, if you want a native user experience inside Fabric, consider adding a Fabric Workload as the front-end/control plane.

    That gives you a clean separation:

    Marketplace = commercial/deployment channel Azure Managed App = Azure-side deployment Fabric APIs = provisioning/orchestration Fabric Workload = optional native Fabric UX

    I'd avoid choosing "SaaS" simply because the product has a web UI. The deciding factor here is that your actual deployed compute is intended to live in the customer's subscription, which is much closer to the Managed Application model.

    I'd also validate the final architecture with the Marketplace onboarding/certification team before implementation, particularly around Fabric tenant prerequisites, service-principal permissions, capacity requirements, and whether every artifact you want to provision has the required Fabric REST API support.

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.