Insights / Microsoft Fabric
Putting Microsoft Fabric Apps to the Test: A Framework KPI Reporting Prototype
We built a framework KPI reporting prototype to test Microsoft Fabric Apps: what it handled well, where it falls short today, and how it compares with the wider shift to high-code web applications.
By Alexandra Joubert · 28 October 2026
Why we built it
Microsoft Fabric now includes Fabric Apps, a way to build applications directly inside Fabric. It is still in preview, and we wanted to know what it can actually do. So rather than read about it in a press release, we built a working prototype against a problem we know well.
The problem we picked is framework KPI reporting, and our test case was the Department for Education’s School Buildings Construction Framework 2025 (CF25). Its handbook sets out the KPIs that contractors on the framework must track and report against.
This is a test of the technology, not a product launch. The prototype exists to find out where Fabric Apps is strong, where it falls short today, and how it compares with the other ways of building an app like this.
The problem: framework reporting still runs on spreadsheets
Frameworks are one of the main routes to public sector construction work, so how well a contractor reports against them directly affects the work it wins. The stakes rose when the Procurement Act 2023 came into force on 24 February 2025. For public contracts worth over £5 million, including call-off contracts under frameworks, buyers must now set at least three KPIs, publish them, and report supplier performance against them at least once a year (GOV.UK KPI guidance). That performance record is public, which makes accurate, timely KPI data a commercial priority rather than an admin task.
Yet many organisations still manage their framework data internally in Excel. And the complexity lands on contractors, because few work on just one framework. Each comes with its own reporting requirements, its own KPI definitions, and its own reporting platform and process, and clients often add KPIs of their own on top.
- DfE CF25Own KPIsOwn definitionsOwn platformOwn process
- Framework BOwn KPIsOwn definitionsOwn platformOwn process
- Framework COwn KPIsOwn definitionsOwn platformOwn process
- Client requirementsExtra KPIsOwn format
Most framework teams we work with lose a large share of their week to collating and checking that data, and the same issues come up again and again:
- Excel holds it all together. Data lives in workbooks emailed between project teams, with little control over versions or who changed what.
- Checking eats the time. Framework teams spend hours chasing late returns and validating figures before anything can be submitted.
- Requirements move. Frameworks update their KPIs, and every template has to change with them.
- It all has to go somewhere. The final data still has to be submitted to each framework, accurately and on time.
What we built
The prototype covers the whole KPI lifecycle, from setting a KPI up to final approval of the data reported against it, with the framework team in control at every step.
-
Set up the project
Each project gets a record holding the client, the framework it reports to (DfE CF25, for example), the contract reference, stage, planned dates, status and how often it must report. The reporting start date sets the deadline for every submission that follows.
-
Define the KPIs
The framework team maintains a central KPI library. Each KPI carries its area, reference, responsible team, the project stage it applies to, whether it is mandatory and where its data comes from, along with the metrics it is built from, each with its own data type and decimal rule.
-
Approve the KPIs
No KPI can be used until it has been formally signed off, and the record shows who approved it and when.
Change an approved KPI and its approval is revoked, so it goes back for sign-off.
-
Submit the data
Project teams enter values for every active KPI on their project, grouped by area such as Health & Safety, and attach supporting evidence. Where a KPI’s data already sits in a Fabric semantic model, its values can be pulled in rather than typed.
-
Approve the submission
Every submission starts as a draft and is submitted for approval. The approver either approves and closes it, or sends it back. Nothing is final until it has been checked.
Returned submissions come back to the project team with a note explaining what to fix.
The KPI library is what makes the rest work. A KPI is defined once, with its metrics and the rules each value must meet, and every project reports it the same way. The definition lives in one place, not in a spreadsheet template per project.
- Type
- Framework · DfE CF25
- Required
- Yes
- Applies to
- All stages
- Responsible
- Health & Safety
| Metric | Captures | Rule |
|---|---|---|
| Reportable events | Count of events | Whole number |
| Headcount | Number of employees | Whole number |
| AFR | AFR ratio | Decimal, 3 dp |
Testing it against the pain points
We used the problems framework teams describe to us as the test brief. This is how the prototype handled each one in Fabric Apps.
| Pain point | What we built in Fabric Apps |
|---|---|
| Every framework reports differently | KPI libraries hold each framework’s KPIs, maintained by the framework team itself |
| Client-specific requirements | KPI types (framework, client and project) let different kinds of tracking sit side by side |
| Requirements change | KPI definitions are edited, re-approved and versioned in the library, not in dozens of templates |
| Hours spent checking data | Approval gates on KPI definitions and submissions protect data integrity |
| Chasing late returns | Outstanding and overdue submissions are flagged for the framework team to follow up |
| No control over who changed what | Audit history captures every change; built-in roles and row-level security control who sees and edits what |
| Reporting and submission | A database backend makes reporting and preparing framework submissions far simpler than stitching workbooks together |
| Another system to log into | It sits inside the Microsoft estate and uses single sign-on |
What we learned about Fabric Apps
The development experience was the pleasant surprise. Fabric Apps uses TypeScript for data modelling, client-side logic and workflows, so with a background in React and TypeScript the build was straightforward. Security comes built in: single sign-on, role-based access control and row-level security, all running on Microsoft’s identity and security services. In the prototype, a user’s role sets what they can do and their data scope sets what they can see, so a project user sees only their own projects while a framework lead sees across the framework.
The limitations are real, though, and most of them come from Fabric Apps being new.
- The full KPI lifecycle, built as a working prototype
- TypeScript throughout: data model, logic and workflows
- Single sign-on, roles and row-level security built in
- Runs inside the Microsoft estate teams already use
- Still in preview, not yet generally available
- Not in every region: not UK South at the time of writing
- Data integration was limited when we built it; data pipelines have since been added
- Sign-in runs through your Microsoft tenant, so check access for anyone outside the organisation
Data integration was the hardest part. When we built the prototype, bringing data into the app from other systems was limited. Microsoft’s latest FabCon updates add data pipeline functionality, which should resolve most of what we ran into. It is also a reminder that a preview changes underneath you: what is hard today may not be next quarter.
Check your region. Fabric Apps is not offered in every Azure region, and at the time of writing it is not available in UK South. If your organisation has data residency or compliance requirements, check Microsoft’s region availability for your Fabric capacity before planning around it.
Beyond Fabric: the shift to high code
Fabric Apps is not the only route we have been exploring. Across the market we are seeing a broader shift away from low-code tools and towards high-code web applications, built in the same languages Fabric Apps uses, TypeScript and React among them. Modern frameworks and AI-assisted development have made them far quicker to build than they used to be.
That makes Fabric Apps an interesting middle ground: high code in how it is written, but hosted inside Fabric with Microsoft’s security around it. A standalone web application trades that convenience for control.
| Fabric Apps | Standalone web application | |
|---|---|---|
| Where it runs | Inside your Fabric capacity | Wherever you choose to host it |
| Sign-in and security | Single sign-on, roles and row-level security built in | Yours to set up, often on the same Microsoft identity services |
| Data | Close to your lakehouses, warehouses and semantic models | Connected through APIs or a database you choose |
| Maturity | Preview, with regional limits | Mature, widely used tooling |
| Best suited to | Internal workflows on data already in Fabric | Wider audiences and custom integrations |
Because both are written in much the same languages, the skills carry across. The real decision is where an app should run and who needs to use it, not how it is built.
Where we landed
Fabric Apps handled a spreadsheet-heavy workflow end to end, inside the Microsoft estate many organisations already run. It is not ready for every case yet: it is in preview, it is not in every region, and its data integration is still catching up. We will keep testing it as it moves towards general availability.
If you are weighing up Fabric Apps or a high-code web application for a workflow of your own, we are happy to compare notes. Get in touch.