Ready to unlock your data's potential?
Join dozens of organizations who have moved to Beyond The Analytics. Book your personalized demo today
See your company like never before
Join dozens of organizations who have moved to Beyond The Analytics. Book your personalized demo today
Decide if a Fabric App can serve clients, partners or citizens: what guest and anonymous access allow, where RLS holds, and the UAE and Saudi gaps.
Co-authored by
Quick answer: Only in narrow cases. A deployed Fabric App signs people in through Fabric SSO on Microsoft Entra ID and nothing else, Microsoft does not document whether B2B guests can open one, and the anonymous access option is meant for public data only.
Government entities and regulated enterprises in the UAE and Saudi Arabia keep asking the same question: can the app the data team built for staff also become the client portal, the partner extranet or the citizen service? For Fabric Apps, external users are the hard part, because the security model assumes people who already sit in your Entra tenant.
This post covers each access path an external audience could take, what Microsoft documents about it as of October 2026, and where the documentation is silent. It ends with a decision table. For what Fabric Apps is and how it compares with a custom web app, read the Fabric Apps overview and the Fabric Apps vs custom web app comparison.
Microsoft's Fabric Apps overview page is still titled "What is Fabric Apps (Preview)?" and states "This feature is in preview." The anonymous data access setting sits under "Fabric apps (preview)" in the admin portal. Everything below describes a preview service.
Quick answer: Fabric SSO signs users in through the Fabric portal with their existing Microsoft Entra ID identity. There is no other identity provider after deployment, so a Fabric App cannot sign citizens in with UAE PASS or Nafath directly.
Microsoft's overview says "Authentication uses Fabric SSO (Microsoft Entra ID single sign-on) exclusively." The Fabric Apps FAQ adds that email and password sign-in "doesn't work after deploying to Fabric," that custom authentication providers aren't supported, and that "you can't deploy an app to Fabric unless authentication is enabled."
The authentication page describes the deployed mode as "Production sign-in for any user with access to your Fabric workspace." Three behaviours matter for a portal:
For an internal tool this is a strength: no password store and no separate identity system to audit. For an external audience it is the constraint that shapes everything else. A citizen with a national digital identity and no account your Entra tenant can authenticate is outside that model.
Quick answer: Microsoft does not document it either way. Fabric shares most items with guests only through workspace roles, so in practice a guest would need a role in the app's workspace, and you should prove the path with a real guest account before you design around it.
The Fabric Apps pages never mention guests, B2B or external users. The overview's sharing guidance covers only "someone in your organization." For anyone planning a partner or client portal, that silence is the most important fact in this post.
What the wider documentation does say:
The probable route for a guest is therefore an Entra invitation, a role in the app's workspace, and Fabric SSO. That is an inference, not documented Fabric Apps behaviour, and it carries a cost: a workspace role reaches every item in that workspace the role covers, not just the app.
Quick answer: A Fabric App has three item permissions. Run and interact lets a user open the app and call its APIs, Edit lets them deploy and change it, and Reshare lets them grant access to others but requires the workspace admin role.
Microsoft's overview lists them in a single table:
| Permission | What it allows | Portal risk |
|---|---|---|
| Run and interact (default) | "Open and use the deployed application. All workspace members receive this level by default." | Any workspace role holder, including a guest, can open the app and call its backend APIs |
| Edit (Write) | Deploy code with rayfin up, apply schema changes, update settings, manage child services | Must never reach an external user |
| Reshare | "Grant other users access to the Fabric app. Requires admin role on the workspace." | Controls who can widen the audience |
Microsoft adds that "workspace roles don't supersede item-level permissions," but because Run and interact is the default for workspace members, membership is effectively access. Two rules follow:
Quick answer: Fabric Apps enforces row-level security in two places: @role policies on the app's own entities, compiled and checked on every API request, and the permissions of the connected Fabric item, which apply because connectors use the signed-in user's delegated access.
The data permissions page defines access with a TypeScript decorator on each entity. A client portal where each user only sees their own requests looks like this:
import { entity, role, uuid, text } from "@microsoft/rayfin-core";
@entity()
@role("authenticated", ["create", "read"], {
policy: (claims, item) => claims.sub.eq(item.ownerId),
exclude: ["internalNotes"],
})
export class ServiceRequest {
@uuid() id!: string;
@text() ownerId!: string;
@text() subject!: string;
@text({ optional: true }) internalNotes?: string;
}Microsoft says the policies are "compiled into data access policy expressions" and that "the data access layer enforces permissions on every API request." That is the right design: the rule lives on the data, not in the UI.
The limits matter for a portal. The documented claims are sub, email and role, and the only documented comparison is .eq(), combined with .and() and .or(). A rule such as "every user at Client A sees every row for Client A" needs an organisation value in a claim or a row-per-user model. The role claim is described as "User role (if provided by identity provider)," with no instructions for populating it from Entra ID, and custom claims in rayfin.yml are app-wide values, not per-user attributes. Test the claim you plan to filter on before you build the data model around it.
Connectors reach a lakehouse SQL analytics endpoint (read only), a warehouse or SQL database in Fabric (read and write), or a semantic model (executeQuery). The connectors page generates auth: type: delegated and says to "keep delegated authentication enabled so connector requests use the signed-in user's access."
Because the request runs as the user, the source item's security, including semantic model roles and warehouse permissions, applies to that user. The page does not spell this out per source, so treat it as a strong inference and test it, as Microsoft itself advises: "Test the deployed app with a user who has the expected permissions on both the Fabric app and the connected item."
For external users this doubles the grant: a role in the app's workspace and permission on the source item, which may sit in another workspace. Each grant is one more place your audit has to look.
Quick answer: Anonymous data access lets people who are not signed in call selected operations on selected entities. It needs a tenant setting that is off by default, an app-level setting and an anonymous role on each entity, and Microsoft warns against exposing any personal, confidential, financial or internal data through it.
The anonymous data access page describes three controls that must all be on:
@role('anonymous', ...) decides "which data and operations those requests can access.""Enabling only one or two of these controls doesn't grant anonymous access." Microsoft's examples include read-only announcements, a create-only feedback form, and a shared list where "anyone with access to this app can create, view, and update every shared todo." Static files are a separate switch: on the hosting page, assetAccess: public "allows anyone with the hosting URL to retrieve hosted assets without signing in."
Security reviewers will compare this with Power BI's Publish to web, where "anyone on the Internet can view your published report or visual." Anonymous Fabric Apps access is narrower, scoped per entity and per operation, but it adds something Publish to web never had: anonymous writes.
| Threat | What it looks like | Control |
|---|---|---|
| Whole-entity exposure | No identity, so no row filter. Every row of an anonymous read entity is public. | Only data cleared for public release. Cut fields with include or exclude. |
| UI bypass | Callers skip your frontend and call the GraphQL API directly. | "Don't rely on the app UI for protection." Set every limit on the data model. |
| Spam and automated writes | A public create entity receives scripted submissions. | Validate input and design public writes "for spam, automation, and unexpected traffic." |
| Tampering | Anonymous update or delete lets anyone change or remove rows. | Never grant update or delete to anonymous on data that matters. |
| Capacity drain | Public traffic consumes the assigned capacity's units. | No anonymous rate limit is documented. Keep public apps off critical capacity. |
| Setting sprawl | The tenant setting is on for everyone, so any builder can publish data. | Limit it to a named security group and review membership. |
| Secrets in the bundle | A public frontend ships keys or connection details. | "Don't store secrets in frontend assets, regardless of the configured hosting access." |
The capacity row is the one most teams miss. Fabric throttles an overloaded capacity, delaying and then rejecting new interactive operations, so a public form that attracts automated traffic can slow every report on the same SKU. Microsoft's capacity guidance recommends isolating critical solutions "in a correctly sized capacity."
Whether an anonymous role works on connector entities is not documented. Connectors use delegated authentication, which assumes a signed-in user, so do not plan to serve semantic model data anonymously.
Quick answer: Microsoft's FAQ states that Fabric Apps does not support tenant or workspace private links, workspace outbound access protection, or application lifecycle management, and has no built-in multi-environment management.
The FAQ's limitations list, verbatim on the points a security review will check:
In practice:
npx rayfin up, so change control lives in your repository process.The troubleshooting page adds two items for the risk register: renaming, retyping or removing a column is not supported, and --force "can cause permanent data loss." Microsoft's overview also leaves you with "legal and compliance accountability for the data your app collects, processes, and stores."
Quick answer: UAE North is not on the list of regions that exclude Fabric App (preview), so UAE-resident deployments are possible. No Saudi Arabia region appears in Microsoft's Fabric region table, so there is no in-Kingdom option for a Fabric App today.
Microsoft's Fabric region availability page, dated 25 September 2026, lists the features missing in each region. As of October 2026:
| Region | Fabric workloads | Fabric App (preview) |
|---|---|---|
| UAE North | All workloads | Not listed as unavailable |
| UAE Central | Power BI only | Not available, since Fabric workloads are not there |
| Qatar Central | Power BI only | Not available, since Fabric workloads are not there |
| Saudi Arabia (any) | Not in the table | No documented option |
The page lists only exceptions, so "not listed as unavailable" is the strongest statement it supports for UAE North.
For Saudi Arabia, Microsoft announced on 31 August 2026 that its Saudi Arabia East region "will be available to customers in November 2026." The announcement does not mention Power BI or Fabric, and the region page warns that "some of the Fabric workloads might not be immediately available in new regions."
Residency is also set per capacity, not per tenant. The Multi-Geo page explains that compute and storage sit in the capacity's region while "some tenant metadata remains in the home region," including permissions. The full residency picture for Power BI and Fabric is in the UAE and Saudi data residency guide.
Quick answer: A portal that handles personal data falls under the UAE PDPL or the Saudi PDPL. For Saudi government entities, the NCA's ECC-2:2024 sends data localization questions to the NDMO, which makes a Fabric App with no Saudi region a question to raise with the NDMO before any build.
Only points the regulators publish themselves:
This is not legal advice; the detail under both PDPLs needs counsel. The practical point is simpler: a UAE entity can host a Fabric App in the UAE today, and a Saudi government entity has no in-Kingdom Fabric region to host it in. For the wider compliance picture, see Power BI for UAE and Saudi government agencies.
Quick answer: Use a Fabric App for audiences already in your Entra tenant and for public, low-risk data. Use Power BI Embedded with app-owns-data for many external clients reading analytics, and a custom application for citizen sign-in, sensitive writes, private networking or Saudi in-Kingdom hosting.
| Audience and data | Use | Reason |
|---|---|---|
| Staff and contractors in your tenant, internal data | Fabric App | The case Microsoft designed it for |
| A small number of named partner staff as B2B guests | Fabric App, after a guest pilot in a dedicated workspace | Guest access is not documented; prove it and accept the workspace-role exposure |
| Public reference data cleared for release, or a feedback form | Fabric App with anonymous read or create | Scoped per entity, but preview, with no documented rate limit |
| Many external client organisations reading reports, each limited to its own rows | Power BI Embedded, app owns data | "App users don't need a license" and don't sign in with Power BI credentials; RLS comes from the embed token's identity |
| Citizens signing in with UAE PASS or Nafath, or any personal-data workflow | Custom application | Fabric Apps supports Entra SSO only |
| Private network required, or formal ALM and change control | Custom application | No private links, no outbound protection, no ALM in Fabric Apps today |
| Saudi government data subject to NDMO localization | Not Fabric today | No Saudi region in the Fabric table; consider on-premises options such as Power BI Report Server |
The Power BI Embedded row deserves a note. Microsoft's embedded analytics page says that with embed for your customers, "your customers are likely to be external users, and they don't need to sign in using Power BI credentials." Your application owns identity, which is what a multi-client portal needs. How effective identity carries RLS and where the licensing threshold falls is covered in embedding Power BI in a custom application.
Cost is a separate decision. Microsoft's Fabric Apps pricing page lists the capacity meters, and the pricing question gets its own post.
The short version for a steering committee: a Fabric App is a good internal tool and an acceptable way to publish public, read-only data. It is not yet a client portal for regulated data. Re-check the FAQ's limitations list and the region table each quarter; those two pages will show when that changes. Beyond The Analytics helps UAE and Saudi entities choose and build the right surface for external analytics.
Microsoft does not document it. The Fabric Apps pages never mention guests, and Fabric's guest sharing page says non-Power BI items reach guests only through workspace sharing. The likely path is a workspace role plus Fabric SSO, which you should confirm with a test guest from a separate Entra tenant, in a workspace that holds only the app.
No. Fabric Apps is in preview, and the "Anonymous data access" tenant setting sits under "Fabric apps (preview)" in the admin portal. It is disabled by default and requires the tenant setting, an app setting and an anonymous role on each entity before any request works without sign-in.
No. Microsoft states that deployed Fabric Apps use Fabric SSO on Microsoft Entra ID exclusively and that custom authentication providers are not supported. A citizen service that signs people in with a national digital identity needs a custom application or another platform that supports that identity provider.
Connectors use delegated authentication, so queries run with the signed-in user's access to the semantic model. That means the model's own security applies to that user. Microsoft tells you to test with a user who has the expected permissions on both the app and the connected item, which is the test to run before go-live.
Not as of October 2026. No Saudi Arabia region appears in Microsoft's Fabric region table. Microsoft has announced the Saudi Arabia East Azure region for November 2026 without mentioning Fabric. The NCA's ECC-2:2024 directs entities to the NDMO on data localization before acting.
No. The Fabric Apps FAQ states that tenant-level and workspace-level private links are not supported at this time, and neither is workspace outbound access protection. If your security baseline requires private network access, a Fabric App does not meet it today.
Microsoft Partner · Dubai
Your business intelligence partner for the GCC
Have a data challenge or a project in mind? Reach out and let's explore how we can help.
Follow us on Google
Make us a preferred source and our analytics writing gets priority in your Top Stories and AI answers.
Add to Preferred SourcesClients we've worked with
Topics