Fabric Apps im Heimrevier von Power BI: Vertrieb und Finance

Was sind Fabric Apps?

Fabric Apps sind ein neuer Item-Typ in Microsoft Fabric, aktuell in der Preview. Microsoft hat sie zur Build 2026 zusammen mit Rayfin vorgestellt, einem Open-Source-SDK und einer CLI. Man schreibt eine Web-App in TypeScript und React, verbindet sie über Konnektoren mit Fabric-Daten und deployt sie mit rayfin up in einen Workspace. Angemeldet wird über Fabric SSO, und jeder sieht nur die Daten, auf die er auch im Modell Zugriff hat.

Für Reporting ist vor allem der Konnektor auf das Semantikmodell interessant. Die App schickt DAX-Abfragen über die Execute-Queries-API an das bestehende Modell. Das Modell bleibt die Datenquelle, die App übernimmt die Darstellung und die Interaktion.

Was wir gebaut haben

Zwei Apps im selben Workspace, beide auf einem bestehenden Semantikmodell. Jede ist in etwa einer Stunde entstanden.

• Vertriebscontrolling: vier Seiten mit Übersicht, Analyse, Pipeline & Forecast sowie Deals & Kunden. Auftragseingang AC gegen PY, integrierte Varianzanalyse, Strukturbrücke, Werttreiberbaum und ein Zoom, der aus einer Grafik Small Multiples macht.
• Finance KPI Cockpit: sechs Kennzahlen gegen Vorjahr, Plan und Forecast, mit wählbaren Plan- und Forecast-Versionen, Forecast schraffiert ab dem ersten offenen Monat, alle Kennzahlen als Tabelle und Ergebnisbrücke.

Was mir besonders gefällt: die Filter über der Seite, gut sichtbar und mit einem Klick gelöscht. Der Zoom mit neuen Aktionen. Und das „Beste": der einfache Wechsel in den Dark Mode. Das hätte ich in Power BI nie gebaut. Dazu steckt jede Ansicht in der URL, also lässt sich genau dieser Stand teilen.

Wie wir es gebaut haben: ein Playbook

Um Fabric Apps zu bekommen, die sich an IBCS-Konzepten orientieren, habe ich meinen Skill mit der MockupKitchen und dem Code meiner Power-BI-Custom-Visuals kombiniert. Daraus ist ein erster Versuch eines Playbooks entstanden: ein reproduzierbares Setup, mit dem mein Coding-Agent über Rayfin solche Apps baut.

Warum wir auf Standards setzen

Fabric Apps können alles, was eine Web-App kann. Genau das ist im Controlling ein Risiko. Ein Finanzbericht wird jeden Monat wieder gelesen, von Menschen, die schnell entscheiden müssen. Dafür braucht man kein fancy Feuerwerk, sondern ein verlässliches Arbeitspferd, das jedes Mal gleich funktioniert.

Ein bekannter Standard dafür sind die International Business Communication Standards (IBCS). Sie legen fest, wie Szenarien, Abweichungen und Strukturen einheitlich dargestellt werden. Seit Juni 2026 gibt es IBCS in Version 2.0, abgestimmt mit der neuen Norm ISO 24896 zur Notation im Business Reporting. Unsere Apps greifen einzelne Konzepte daraus auf:

Dazu kommen Abweichungen als eigene Grafik, eine einheitliche Skalierung und eine klare Farbe für gut und schlecht. Statt Grün nehmen wir unser Kitchen-Teal, damit die Farben auch bei Rot-Grün-Sehschwäche unterscheidbar bleiben.

Mit einem Coding-Agent wird ein Standard noch wertvoller. Er ist eine Spezifikation, die der Agent befolgen kann. Ohne Standard erfindet der Agent bei jeder App ein neues Design, und jede App muss man neu lesen lernen. Mit Standard sieht die dritte App aus wie die erste, und Leser erkennen AC, PY, Plan und Forecast sofort wieder. Das macht das Ergebnis reproduzierbar, und genau darum geht es beim Playbook.

Git: ein sauberer Workflow, auch ohne offiziellen Support

Reproduzierbar heißt für mich auch: versioniert. Der Workspace hängt deshalb über die Fabric-Git-Integration an einem privaten GitHub-Repository. Semantikmodelle, Berichte, Lakehouse und die anderen Items werden dort automatisch synchronisiert.

Bei den Apps steht in der Quellcodeverwaltung von Fabric aber „Unsupported". Fabric Apps gehören im Moment noch nicht zu den Items, die Microsoft für die Git-Integration unterstützt. Fabric lässt sie beim Sync einfach liegen. Das ist kein Fehler im Setup, sondern der aktuelle Stand der Preview.

Darauf wollten wir nicht warten. Den Quellcode der Apps haben wir deshalb extra in dasselbe Repository gelegt, in einen eigenen Ordner neben den Items aus der Fabric-Synchronisation. Fabric ignoriert diesen Ordner, weil er keine Item-Definitionen enthält. So folgt auch die App-Seite einem sinnvollen Workflow:

• Ein Repository für alles: Modell, Bericht und App-Code liegen zusammen und haben eine gemeinsame Historie.
• Branches und Merges: Änderungen an den Apps laufen über einen eigenen Branch und werden per Merge übernommen, wie bei jedem anderen Code.
• Keine Geheimnisse im Repo: Umgebungsdateien, Deployment-Zustände und Datenexporte bleiben draußen. Nach dem Klonen werden sie lokal neu erzeugt.
• Neu aufbauen statt kopieren: Aus dem Repository lässt sich jede App mit rayfin up in einen anderen Workspace deployen, etwa in einen eigenen Demo- oder Test-Workspace.

Sobald Microsoft das App-Item in die Git-Integration aufnimmt, kann der Ordner in den normalen Sync wandern. Bis dahin ist das der pragmatische Weg.

Was man bedenken sollte

Es ist nicht alles Sonnenschein. Diese Punkte gehören zur ehrlichen Bewertung dazu:

• Rechenlogik wandert in den App-Code. Wenn die App Kennzahlen im Browser rechnet, liegt diese Logik nicht mehr im Semantikmodell. Sie muss getestet und dokumentiert werden, sonst gibt es zwei Wahrheiten.
• Governance. Die Fabric-Git-Integration unterstützt das App-Item noch nicht. Den Workaround mit eigenem Ordner im Repository muss man bewusst pflegen, siehe oben.
• Preview und Regionen. Fabric Apps sind Preview, der Tenant-Admin muss sie freischalten, und nicht jede Region unterstützt sie.
• Kapazität und Grenzen. Apps verbrauchen Capacity Units, und kleine Kapazitäten drosseln schnell. Die Execute-Queries-API hat Grenzen bei Zeilen und Abfragen pro Minute.
• Kein Ersatz für Power BI. Für viele Berichte bleibt ein Power-BI-Bericht der einfachere Weg. Fabric Apps lohnen sich dort, wo Interaktion den Unterschied macht.

Warum das sinnvoll ist

Fabric Apps sind eine Ergänzung, kein Ersatz. Spannend werden sie, wenn man sie mit Standards und einem Playbook kombiniert. Dann bekommt man die Freiheit einer Web-App, ohne bei jeder App bei null anzufangen. Das Semantikmodell bleibt die Quelle, die Notation bleibt gleich, und der Agent baut in einer Stunde, was sonst Tage an Design und Abstimmung kostet.

Das ist ein erster Versuch. Was denkt ihr? Ich freue mich über Feedback, Kritik und eigene Experimente.