Fabric Apps Get a Backend: The Last Mile of a Finance Workflow

A cost-centre owner opens the month-end variance report, finds a line that is well over budget, and then does the one thing the report cannot help with: types an explanation into an email or a cell in a shared workbook, from where somebody will paste it into the management pack by hand. The number came out of a governed semantic model. The decision about the number lives in a spreadsheet.

Microsoft used FabCon Europe in Barcelona to go after exactly that gap. Fabric Apps, the application layer it launched in June, picked up backend functions, file storage, PostgreSQL, built-in usage metrics and a family of connectors to data that already sits in Fabric. For a finance team the release is less about building apps than about where the second half of a reporting workflow is allowed to live.

What was announced in Barcelona

Fabric Apps are built with Rayfin, a code-first TypeScript framework. You (or a coding agent) describe the application, and Rayfin's SDK and CLI generate typed APIs and clients, run the whole thing locally, and deploy it as a Fabric item where the database, storage, connectors, functions and authentication are hosted for you. The product team reports that more than 15,000 developers have built a Fabric App since the June launch, and notes that many of them are not developers by job title: designers, product managers and finance teams building tools for the workflows they know best.

The September additions fill in the parts that were missing for anything beyond a prototype:

• Data connectors to Fabric SQL databases, warehouses, lakehouse SQL analytics endpoints and semantic models, with schemas discovered automatically.
• PostgreSQL as a second option next to SQL Server for app-owned data.
• Storage for files, defined in code with folders, accepted file types, size limits and permissions.
• Functions for server-side TypeScript logic, plus a Secret Store that hands credentials to functions only at runtime.
• App metrics out of the box: sign-ins, app loads, query volume, query errors, error rate and average query duration.

Querying the model instead of rebuilding it

The connector that deserves the most attention from a BI team is the semantic model one. An app can send a DAX query to the model and receive the same answer every report consumer receives. Revenue, margin and budget variance stay defined once, as measures the business has already argued about and signed off, and the application calls them instead of reimplementing them in JavaScript.

The announcement shows the pattern in two short pieces. Here it is, reshaped around a variance-commentary screen:

# rayfin.yml: declare the governed sources the app is allowed to reach
connectors:
  - name: ledger
    type: fabric-warehouse
    config: { workspaceId: ${WS_ID}, itemId: ${WAREHOUSE_ID} }
    auth: { type: delegated }      # runs as the signed-in user
  - name: closeModel
    type: fabric-semanticmodel
    config: { workspaceId: ${WS_ID}, itemId: ${MODEL_ID} }
    auth: { type: delegated }

// Read: ask the semantic model, so the app shows the signed-off measures.
const variances = await client.connectors.closeModel.executeQuery({
  query: 'EVALUATE TOPN(20, CostCentreVariance)',
});

// Write: keep the explanation as a record in the app's own database.
await client.data.VarianceComment.create({
  costCentre, period, comment,     // values captured from the form
});

Nothing is copied out of the warehouse or the model to make this work, which matters more than it sounds. Every copy of finance data is one more thing to reconcile, one more lineage question in an audit, and one more refresh that can fail on working day three.

Two identities, and the choice between them is a control

With auth: { type: delegated } the connector runs as the signed-in user, and the source enforces its own authorization, row-level security included. A regional controller who can see only their region in the Power BI report sees only their region in the app. The alternative is application identity, for cases where the app legitimately needs its own permissions. The announcement is blunt about the consequence: an application identity does not inherit the user's permission boundary, so "choose deliberately".

That sentence should be read as an access-control decision and documented like one. Delegated identity keeps the existing RLS design in force. Application identity moves the enforcement into the app's code, where it has to be designed, tested and reviewed by someone. Functions make the question sharper, because they run under the app identity and can forward the signed-in user's context to downstream calls.

Microsoft also separates two questions that tend to get merged in conversations with auditors. Authentication decides who may open the application, and it happens through Microsoft Entra before any application content is delivered. Fabric permissions decide which data that person can reach once inside. Apps are private by default, public access exists only for approved anonymous scenarios, and tenant-level controls let administrators limit how apps can be exposed at all.

Somewhere to write

A dashboard is read-only, and the last mile of a finance process is almost entirely writing: the comment, the approval, the adjusted accrual, the supporting PDF. App-owned data lands in a managed database whose schema ships with the application as code, so there are no connection strings to pass around and no migration script on someone's laptop. Attachments go to storage, and the record keeps a reference to the file.

The global expense dashboard I built at Morgan Stanley put automated variance analysis in front of more than fifty users. A model can compute a variance for every one of them. Explaining it is a human act, and the explanation is only worth something if it is stored against the period, the cost centre and the person who wrote it. That is the piece Fabric Apps now has room for, and because the app's database is itself an item in the workspace, the commentary becomes data that next month's report can query.

Read and write, source by source

The read-only rows are a feature. A semantic model that an app cannot write to is a model whose numbers still come from one refresh path.

What the preview does not cover

Fabric Apps is in preview, and the documentation is candid about its edges. The workspace needs a Fabric capacity, the app's services consume capacity units from it, and a tenant administrator has to enable the workload first. Not every region is supported yet. After deployment, sign-in is Fabric single sign-on only. Microsoft's own guidance says the platform may not suit applications that need complex multi-step transactions or stored procedures, which rules out a fair amount of what a subledger does.

The roadmap for later in 2026 tells you what is missing today: an admin and security portal, deployment pipelines, embedding, custom claims, a Kusto connector and app sharing with provenance. Until deployment pipelines exist, promotion between environments is something you design yourself. One smaller detail from the docs is worth a line in your access review as well: every workspace member receives permission to run the app by default.

And the announcement's warning about agent-written code applies fully. Generated code is a starting point, typed entities catch mismatches during development, but neither replaces runtime validation, authorization checks or a code review.

A sensible first app for a finance team

The product team's own advice is to pick a single workflow that starts in a dashboard and ends in a spreadsheet, and build the ending. For most finance teams the candidates are easy to list: variance commentary, accrual confirmations, approval of manual journals above a threshold, cost-centre mapping maintenance. Each is small, each is run by people who know it better than any engineering team, and each currently leaves its evidence in mailboxes.

Start with the delegated-identity version, keep the semantic model as the only source of numbers, and treat the app's database as a new system of record that needs an owner and a retention rule. The full walkthrough, including the storage and functions examples, is in Microsoft's post From prompt to production: What's new in Fabric Apps, and the Fabric Apps overview on Microsoft Learn lists the current prerequisites and limits.