One model, two jobs: testing write-back workflows in Microsoft Fabric Apps

Most organisations run two parallel data worlds. There's the analytics estate — the warehouse, the semantic model, the dashboards — and there's the operational estate, which is where the actual work happens: leave requests, asset registers, inspection checklists, service tickets. The second one almost always gets built somewhere else, on its own database, with its own permissions model and its own definition of who reports to whom.

Then someone asks for a report across both, and you discover the operational app's data has a different grain, different codes, and a security model that doesn't reconcile with the one in your semantic model. I've spent a lot of billable hours on that reconciliation.

So when Fabric Apps appeared, the question I actually cared about wasn't whether it could build a form. It was whether the operational write-back and the reporting could sit on the same governed model — and whether row-level security would hold across both.

What I built

An employee leave tracker. Deliberately mundane, because mundane is where this either works or doesn't. The requirements were the ones any organisation would recognise:

• Employees submit leave requests through the app
• Requests are written directly to a Fabric database
• Managers approve or reject them
• Records update immediately
• Row-level security means people only see the data they're permitted to see
• Reporting sits on top of the same governed data — not a copy of it

That last point is the whole exercise. A leave tracker is trivial. A leave tracker whose approvals feed the same model your headcount and cost reporting runs on is a different proposition.

Setting it up

Less involved than I expected. From a standing start:

1. In the Admin portal, enable Fabric App items
2. In the Admin portal, enable the Semantic Model Execute Queries REST API
3. In your workspace, create a new item — Fabric App
4. Copy the prompt from the Fabric App screen and post it into your AI assistant
5. Answer the assistant's follow-up questions as it works through the build

Two admin toggles and a workspace item. If you don't have a tenant to experiment in, this runs on a Fabric trial, which is how I'd suggest testing it before raising it with anyone's platform team.

The two things that surprised me

The database got built for me

I expected to model the tables myself and wire the app on top. Instead the AI created the database as part of the build. For a prototype that's a substantial time saving. For production I'd want to review every column type, key and constraint it chose — generated schemas are a starting point, not a design — but as a way to get from idea to working prototype in an afternoon, it's genuinely fast.

Row-level security held

This is the finding that changes what the tool is for. Fabric Apps leans on the semantic model rather than going around it, and it respects RLS. Which means the permissions you've already defined for reporting extend to the operational surface, instead of being reimplemented — differently, and slightly wrong — in a second system.

Anyone who has maintained two divergent security models for the same organisational hierarchy will recognise why that's worth more than the app itself.

Where this fits, and where it doesn't

I don't think this replaces Power BI dashboards, and I'd be cautious of anyone who says it does. The division of labour looks reasonably clear to me:

• Power BI continues to serve structured reporting and KPI monitoring — the views people open every Monday, where consistency matters more than flexibility
• Fabric Apps opens up AI-driven exploration and operational workflows on the same governed foundation — the ad-hoc question, and the process step that generates the data

Once you frame it as operational workflows on governed data, the candidates multiply quickly. Approvals of any kind. Asset tracking. Inspections. Audits. Service requests. All of these are currently built in separate tools and then painfully joined back to the analytics estate later.

What I'd want before putting it in production

Being clear about this matters more than the enthusiasm. It's a preview feature at the time of writing, and I'd want answers on several fronts before recommending it for anything a client depends on:

• Schema review. Generated tables need the same scrutiny as any other data model — grain, keys, types, constraints, referential integrity
• Change control. How does an app move from development to test to production, and what does version history look like? I hold BI assets to the same standard as application code, and I'd want the same here
• Audit trail. For approvals in particular, who changed what and when is not optional, and it needs to survive a model refresh
• Concurrency. Two managers acting on the same request at the same time is a matter of when, not if
• Preview terms. Feature behaviour and support commitments change before general availability, which is a real consideration for anything load-bearing

None of that is a reason to ignore it. It's the list I'd work through with a platform team before letting it near a live process — and the fact that the list is this short is itself notable.

Why I think this direction matters

The recurring problem in my work isn't that organisations lack tools. It's that the chain from source system to decision has too many owners and too many copies of the truth. Every additional system that holds its own version of "who reports to whom" or "what counts as approved" is another place the numbers can diverge.

A platform where the operational process and the reporting genuinely share one governed model is a structurally different proposition from integrating two systems well. I'd want to see it mature before betting a client's process on it. But the direction is the right one.

I'd be interested to hear what use cases others are testing — particularly anyone who has taken it past prototype.