Microsoft Fabric has been the place where organizations collect, prepare and analyze data. Acting on what that analysis shows has usually happened somewhere else: in a spreadsheet, a ticketing system or a separately built application.
Fabric Apps, currently in preview, closes part of that gap. It is a Fabric workload for building data-driven business applications: software with its own interface, records and rules, hosted and secured inside Fabric, that can read the same governed data your reports use. Developers describe the application's data in TypeScript, and Fabric generates the database, the API, sign-in and hosting around it.
This article explains where Fabric Apps fits in Fabric, what a Fabric app is made of, how it uses existing Fabric data, how access is controlled, where AI agents fit, and when Fabric Apps is worth evaluating.
Where Fabric Apps Fits in Fabric
Fabric already covers three layers of analytics. OneLake, lakehouses and warehouses store the data. Power BI semantic models define the agreed measures and relationships. Reports present the results.
A Fabric app adds a fourth layer: the place where people act on those results. It can collect input, keep its own records, apply business rules and record decisions, while reading the governed data underneath instead of copying it.
| Power BI report | Power BI app | Fabric app | |
|---|---|---|---|
| What it is | Interactive pages over a semantic model | A packaged set of reports for an audience | An application with its own records and rules |
| Answers | What happened? | Where do I find the reports? | What do we do next, and who decided? |
| Stores new data | No | No | Yes, in its own database |
| Changes data | No | No | Yes, within the permissions you define |
The word "app" in Power BI means a distribution package. A Fabric app is software a team writes, reviews and operates.
What a Fabric App Is Made Of
A Fabric app runs as a managed service inside a Fabric workspace. When it is deployed, Fabric creates three parts that appear as child items in the portal:
- A SQL database in Fabric holds the app's own records. Its tables come from the app's data model, so schema changes are made in code, not in the database.
- Authentication uses Fabric single sign-on with Microsoft Entra ID. After deployment, this is the only supported sign-in.
- Static hosting serves the app's web interface.
The app's code reaches these parts through one backend URL that exposes a GraphQL data API, a query interface through which the interface reads and changes records.
The data model is the core of the app. Each kind of record is a TypeScript class marked as an entity, with fields that set its types and constraints and relationships to other entities. From those definitions, Fabric Apps generates the database tables, the API, typed client code and the permission rules. The toolkit behind this is the Rayfin SDK and command-line tool, which also runs the full stack locally and deploys it to a workspace.
An app keeps its own records and reads governed data.
How an App Uses Existing Fabric Data
Connectors give an app typed access to other Fabric items without building a separate data service. They do not all allow the same operations:
| Fabric item | What the app can do |
|---|---|
| Semantic model | Run DAX queries. No writeback to measures. |
| Warehouse | Read, and create, update or delete if configured. |
| SQL database in Fabric | Read, and create, update or delete if configured. |
| Lakehouse SQL endpoint | Read only. |
Connectors use delegated authentication: a query runs with the signed-in user's own access to that item, including the item's own security. The app cannot see more than the person using it.
The design question is which system stays the source of truth. A semantic model remains the authority for an agreed measure; the app should query it, not recalculate it. Reliancy recommendation: start with read-only connections to existing data and write only to records the app owns. Add writes to another operational system only when that system's owner has agreed the operation, its validation and how to reverse it.
How Access Is Controlled
Signing in proves who someone is. Three separate checks then decide what they may do:
- Item permissions on the app. Run and interact lets someone use the app, Edit lets them deploy code and schema changes, and Reshare lets a workspace admin grant access to others.
- Data permissions on the app's records. Rules attached to each entity state which roles may create, read, update or delete. They can restrict rows using the signed-in user's claims, such as "only records this user owns", and restrict which fields a role may set. The data API enforces them on every request, not only in the interface.
- Access to connected Fabric items. Through delegated authentication, each source applies its own permissions to the user.
Signing in proves identity. Three checks decide what is allowed.
Fabric provides the sign-in, the row-level rules and the item permissions. The team remains responsible for what the app exposes, for keeping secrets out of the code and frontend, and for the compliance of the data it collects.
Where AI Agents Fit
Microsoft lists AI and agent applications that need persistent state among Fabric Apps' intended uses. That is the useful role: an agent can read permitted data and propose a change, such as a summary, a classification or a suggested owner, while the app holds the proposal as a draft.
The agent proposes. The app checks. A person decides.
The app then checks what the agent cannot reliably check about itself: that the records it cites exist, that the person accepting has the right role, and that the data is current. Only an accepted proposal becomes a record, written under that person's identity and permissions.
Agents also help build Fabric apps. Microsoft's documented workflow includes developing with GitHub Copilot, and Microsoft has announced app creation from natural language in Power BI Desktop, built on Fabric Apps, as a forthcoming preview. Generated code still needs the same review as any application: the schema diff, the permission rules and tests as restricted users.
When Fabric Apps Is a Good Fit
A good fit:
- You already trust the data in Fabric, and the next step is a decision or input that someone must record.
- The workflow is internal, bounded and owned by one team.
- You want an agent to prepare work while people keep the decision.
A weaker fit:
- The real need is another report page.
- The process needs complex multi-step transactions or stored procedures, which Microsoft lists as unsuitable.
- Users must sign in with something other than Fabric single sign-on after deployment.
Availability: Fabric Apps is preview. A tenant administrator must enable the workload, the workspace needs Fabric capacity, and it is not yet available in every region.
Questions to Answer Before a Pilot
- Which decision or input should the app record, and who owns it?
- Which Fabric items remain the source of truth, and does the app only read them?
- Which roles may create, read, update or delete each kind of record?
- Where would an agent propose, and who accepts its proposals?
- Is Fabric Apps enabled, with capacity, in your region and tenant?
Discuss a bounded Fabric application pilot with Reliancy.