%20-%20Teams%20Logo.png?width=576&height=182&name=Logo%20in%20standard%20arrangement%202%20(RGB)%20-%20Teams%20Logo.png "Epic Fusion")
Power Apps Code Apps: Die Power Platform kann jetzt fast alles. Das ist das Problem.
Eine App bauen war nie das Problem. Sie zu betreiben schon. Login. Rechte. Hosting. Monitoring. Sicherheitsprüfungen. Deployment. Was bei einer internen Anwendung oft nach dem eigentlichen Build beginnt, kostet Teams Zeit, Geld und Nerven. Genau dieser Teil verändert sich gerade.
Mit Power Apps Code Apps entwickelst du eine ganz normale moderne Web-App mit React, TypeScript und Vite. Und dabei veröffentlichst du sie mit einem Befehl in die Power Platform, wo Anmeldung, Freigabe, Verwaltung und Monitoring schon vorhanden sind. Parallel dazu gibt es mit Generative Pages in model-driven Apps eine Funktion, mit der du eine App-Seite beschreibst und daraus einen echten React-Code erhältst. Das Entscheidende daran ist nicht, dass Microsoft jetzt auch KI kann. Oder dass React plötzlich in Power Apps auftaucht. Die Grenze zwischen Low-Code und klassischer Softwareentwicklung fällt gerade auseinander. Und zwar von beiden Seiten gleichzeitig.
Die Trennung zwischen Low-Code und Pro-Code war ohnehin künstlicher, als wir gerne zugegeben haben.
In der Power Platform gibt es seit Jahren eine unsichtbare Trennlinie. Auf der einen Seite Low-Code. Schnell, governt, aber irgendwann stösst du an die Grenze dessen, was sich mit Standardkomponenten abbilden lässt. Auf der anderen Seite klassische Webentwicklung: Volle Freiheit, aber jedes Projekt beginnt bei null (Authentifizierung, Rollenmodell, Hosting, Deployment-Pipeline, Logging). Und am Ende die unangenehme Frage aus der IT-Sicherheit: Wer hat das eigentlich geprüft?
Was gerade passiert, ist bemerkenswert: Die Trennung zwischen Low-Code und «richtiger» Entwicklung war schon immer künstlicher, als wir gerne zugegeben haben. 2026 fällt sie nun endgültig auseinander.
Von der Code-Seite kommen Code-Apps, mit denen Entwickler in ihrer gewohnten IDE arbeiten, aber in der Power Plattform landen. Von der Low-Code-Seite kommen Generative Pages, die aus einer Beschreibung produktionsnahen TypeScript- und React-Code erzeugen. In der Mitte treffen sich beide bei React-Komponenten, die in einer verwalteten Unternehmensumgebung laufen.
Power Apps Code Apps: Eine normale Web-App, nur ohne den ganzen Infrastrukturballast.
Microsoft beschreibt Code-Apps sinngemäss so: Power Apps-Fähigkeiten in eigene, code-first entwickelte Webapplikationen bringen. Du entwickelst lokal. Du verwendest bekannte Frameworks wie React oder Vue. Du hast volle Kontrolle über UI und Logik. Und trotzdem läuft die Anwendung anschliessend innerhalb der Power Platform.
Eine Beschreibung aus der Community bringt es auf den Punkt: Die erste Code-App ist «a regular modern web app that becomes a managed Power Platform app». Kein eingeschränkter Baukasten, kein «geht leider nicht, weil die Komponente das nicht kann». Ist ein Design-System vorgegeben, wird es umgesetzt. Muss eine Interaktion speziell sein, wird sie gebaut. Das ist Webentwicklung.
Der Weg von der Idee bis zur produktiven App.
Der technische Ablauf ist für alle, die schon einmal eine Web-App deployt haben, erstaunlich unspektakulär. Doch genau das ist das Kompliment.
- Projekt aus einem offiziellen Vite-Template von Microsoft erzeugen.
- Power Apps CLI installieren und die App mit einem Init-Befehl an eine Power Platform-Umgebung binden – dabei meldest du dich schlicht mit dem Power Platform-Konto an.
- Lokal testen über «Local Play». Die App läuft auf deinem Rechner, spricht aber bereits mit der Umgebung.
- Build und Push: Die CLI gibt eine Power Apps URL zurück. Ab diesem Moment lässt sich die App wie jede andere App im Power Apps Portal starten, teilen und verwalten.
Das ist der Moment, in dem es bei den meisten Teams klickt. Ein Push und die App liegt im Unternehmensportal. Mit Anmeldung, Freigabemechanismus und Verwaltung. Ohne dass jemand eine Zeile Login-Code geschrieben hat. Was du stattdessen aus der Plattform bekommst, ist genau das, was ein Eigenbau teuer macht: Sign-in und Kontoverwaltung, Application Lifecycle Management, Monitoring über Azure Application Insights, eine konfigurierbare Content Security Policy und Publishing über einen Service Principal für automatisierte Deployments.
Die Daten sind nicht das Problem. Die Daten sind schon da.
Ein häufiger Bremsklotz interner Projekte ist nicht die Oberfläche, sondern der Zugang zu den Daten.
Code-Apps binden sich an Dataverse, an Azure SQL, an SharePoint und an Copilot Studio an. Bestehende Power Automate Flows lassen sich direkt in die App einbinden.
Wer schon Prozesse in Power Automate abgebildet hat, baut also keine neue Logik. Im einfachsten Fall bekommt sie einfach eine neue Oberfläche. Und wer eigene Backend-Logik braucht, kann erweitern: Microsoft dokumentiert unter anderem eine einfache Asset-Management-API mit Azure Functions als Ergänzung.
Das ist der Punkt, an dem Code-Apps interessant werden. Nicht weil jetzt plötzlich jeder Low-Code-Entwickler React schreiben muss. Sondern weil Teams nicht mehr zwingend zwischen voller Frontend-Freiheit und Power Platform Governance wählen müssen.
Generative Pages: Wenn model-driven Apps plötzlich ein eigenes Frontend bekommen.
Model-driven Apps waren immer die solide, unaufgeregte Seite der Power Platform: datenmodellgetrieben, konsistent, governt und optisch sehr standardisiert. Wer eine wirklich eigene Ansicht brauchte, landete schnell bei Custom Pages oder bei einem Kompromiss.
Generative Pages setzen hier an. Und nein: Das ist nicht einfach «KI baut mir schnell eine hübsche Seite». Die spannendere Entwicklung ist eine andere. Eine der klassischen Grenzen der Power Platform wird durchlässig. Bisher galt oft: Entweder du akzeptierst die Standardoberfläche oder du verlässt die Welt der Standardoberfläche und baust selbst. Generative Pages bewegen sich dazwischen.
Eine Seite beschreiben statt bauen.
Du beschreibst in natürlicher Sprache, was du brauchst, benennst die relevanten Dataverse-Tabellen und kannst sogar ein Bild anhängen, wie die Seite aussehen soll, bis hin zu einer, im Wortlaut von Microsoft «rough napkin sketch».
Daraus wird ein React-Code generiert, der sowohl das Frontend-Erlebnis abdeckt – Auswahl der passenden Komponenten, bestes Layout – als auch die zugehörige Business-Logik. Danach geht es im Dialog weiter: Elemente lassen sich verändern, Layouts anpassen und Funktionalitäten erweitern.
Wichtig für alle, die Governance ernst nehmen: Generative Pages sind solution-aware. Sie erscheinen als «UX Agent Project»-Zeilen und lassen sich zwischen Umgebungen exportieren und importieren. Der normale ALM-Prozess greift also. Und bevor Nutzende eine Seite sehen, müssen sie explizit publiziert werden. Es rutscht nichts versehentlich in Produktion. Und die Seiten sind keine Inseln: Sie nehmen Input-Parameter entgegen und werden über die reguläre model-driven Navigation aufgerufen. Echte Bausteine im Fluss der App, nicht ein hübsches Anhängsel.
Der spannendere Weg führt über die Entwicklungsumgebung.
Generative Pages gibt es auch direkt im Browser innerhalb des App Designers. In der Praxis ist dieser Weg aber regional beschränkt und für uns in Europa aktuell keine Option. Der interessante Weg ist ohnehin der andere und Microsoft nennt ihn ausdrücklich den empfohlenen: die Arbeit aus der Entwicklungsumgebung mit KI-Code-Tools wie der GitHub Copilot CLI oder Claude Code.
Die Gründe sind handfest: Zugriff auf die neuesten Frontier-Modelle, weltweite Verfügbarkeit in Public Clouds und du kannst in einem einzigen Durchlauf mehrere Seiten plus die dazugehörigen Dataverse-Tabellen bauen. Die Funktion selbst ist inzwischen global verfügbar.
Dahinter steckt ein orchestriertes Vorgehen: Ein Planner-Agent analysiert die Anfrage und schlägt einen Plan vor – welche Seiten, welche Tabellen, welche App, welche Solution – und delegiert dann an spezialisierte Agenten wie einen Table Builder und einen Page Builder, die produktionsnahen TypeScript- und React-Code erzeugen. Optional gibt es einen «verify-in-browser»-Schritt mit automatisch generierten Playwright-Tests.
Auch der Sprachaspekt ist auf diesem Weg gelöst: Der Agent erkennt alle in der Umgebung aktivierten Sprachen und generiert entsprechenden Code. Die Seite respektiert danach die individuellen Regionaleinstellungen für Datum, Zahlen und Währung.
Copilot Chat und Form Fill Assistance: Die KI zieht weiter in die Fachanwendung ein.
Model-driven Apps bringen heute nicht nur generierte Seiten mit. Mit Copilot Chat können Endnutzer Fragen in natürlicher Sprache zu den Daten ihrer Anwendung stellen und direkt Antworten erhalten. Dazu kommt die Form-Fill-Assistenz, die bei komplexen Formularen Vorschläge auf Basis des vorhandenen Datenkontexts macht. Für Dynamics 365 Nutzer sind diese Funktionen allgemein verfügbar und standardmässig aktiviert. Für Standalone Power Apps befinden sich beide weiterhin in Public Preview und müssen im Power Platform Admin Center aktiviert werden. Die Richtung ist trotzdem klar: Die Oberfläche wird nicht nur generativer. Die Anwendung selbst wird zunehmend dialogfähig.
Welche Power-Platform-App für welchen Use Case?
Die häufigste Frage in Workshops lautet nicht «Was kann die Plattform?», sondern «Was nehme ich wofür?». Microsoft hat an der European Power Platform Conference 2026 in Kopenhagen eine Landkarte gezeigt, die das gut sortiert.
Von oben nach unten gibst du Führung ab und gewinnst Freiheit. Alles ausser Power Pages BYOC ist für interne Nutzende gedacht. Wer eine anonym erreichbare Oberfläche braucht, ist auf dieser Landkarte ganz rechts.
Model-driven Apps
Eine model-driven App ist die richtige Wahl, wenn die Anwendung stark daten- und prozessgetrieben ist und du eine konsistente, verwaltete Oberfläche brauchst. Aus dem Datenmodell gebaut, einheitliche Oberfläche, Offline und Berechtigungen inklusive.
Geeignet für interne Nutzer.
Generative Pages
Eine Generative Page ist interessant, wenn du innerhalb einer bestehenden model-driven App bleibst, aber für einen bestimmten Prozess oder eine bestimmte Ansicht deutlich mehr Freiheit beim UI brauchst. Konkret: KI-geschriebener Code in der model-driven App, verbindet beide Welten, weltweit verfügbar.
Geeignet für interne Nutzer.
Vibe Apps (Preview)
Interne Anwendungen, die schnell und KI-gestützt entwickelt werden sollen. Vom Agenten generiert und innerhalb der Leitplanken der Plattform, Du beschreibst es und die Plattform baut es.
Geeignet für interne Nutzer.
Code Apps
Code Apps sind interessant für eigenständige SPAs, moderne Entwicklungsteams und Anwendungen, bei denen das Frontend mehr ist als eine leicht angepasste Dateneingabemaske. Du bekommst volle Kontrolle über UI und Logik und arbeitest mit einem React- oder Vue-Modell.
Geeignet für interne Nutzer.
Canvas Apps
Es gibt auch den Bereich dazwischen. Ein gemischtes Team aus Makern und Entwickler. Ein schneller Low-Code-Kern, ergänzt durch individuelle Komponenten. Pixel Perfekte Entwicklung, neu auch mit KI-Agenten (aktuell in Preview) und smartphone Unterstützung.
Geeignet für interne Nutzer.
Power Pages BYOC
Sobald eine Anwendung öffentlich erreichbar sein soll oder externe Nutzer ein anderes Routing- und Zugriffsmodell benötigen, verschiebt sich die Architektur. Full-Stack, serverseitige Logik, eigener Code, eigenes Hosting.
Geeignet für externe Nutzer.
Der Realitätscheck: Was passiert, wenn du falsch wählst?
An derselben Konferenz haben Vivian Voss und Yannick Reekmans eine Tabelle gezeigt, die ich für die brauchbarste Entscheidungshilfe zum Thema halte. Sie stellt nicht die Frage «Was ist möglich?», sondern «Was geht schief, wenn ich mich falsch entscheide?».
Zwei Dinge fallen daran auf:
-
Zweimal lautet die Antwort «Standardformular» oder «Canvas + PCF». Die neuen Möglichkeiten sind nicht automatisch die richtige Antwort. Die häufigste Fehlentscheidung ist nicht «zu wenig Technik», sondern zu viel.
-
Die Spalte mit den Fehlermodi ist der eigentliche Wert. Generative Page, wenn du im Kontext der model-driven App bleiben und ihr Sicherheitsmodell erben willst. Code App, wenn die Anwendung eigenständig sein soll, mehr als Dataverse braucht oder das Frontend als echtes Engineering-Artefakt behandelt werden muss.
Und häufig ist die richtige Antwort nicht «entweder-oder», sondern: die Fachanwendung als model-driven App, die anspruchsvolle Spezialansicht als Generative Page, die eigenständige Oberfläche als Code App. Alle drei in derselben Umgebung, unter demselben Rechtemodell.
Ehrlich bleiben: Grenzen und Verantwortung.
Ein Beitrag, der nur schwärmt, hilft dir bei der Planung nicht. Diese Punkte gehören auf den Tisch:
-
Der generierte Code ist nicht automatisch produktionsreif oder konform mit den Standards deiner Organisation. Microsoft formuliert das ungewöhnlich klar: Der Agent unternimmt einen «best-effort attempt», vollständigen, produktionsreifen Code inklusive Accessibility- und Security-Best-Practices zu erzeugen. Die Verantwortung für die Validierung bleibt trotzdem beim Team. Er muss getestet und überprüft werden, bevor er publiziert wird. Das ist kein Nachteil, sondern ein normaler Review-Schritt, wie bei jedem Code.
-
Technische Randbedingungen bei Generative Pages: ausschliesslich Dataverse als Datenquelle, maximal sechs Tabellen pro Seite, kein gleichzeitiges Arbeiten mehrerer Maker an derselben Seite, sowie Prompt-Limit von 50'000 Zeichen. Das sind keine Gründe, die Funktion nicht zu nutzen. Aber sie gehören in die Architekturentscheidung.
-
Code Apps müssen in der Umgebung freigeschaltet sein – das ist eine Admin-Handlung, keine Selbstbedienung. Auch das Tooling entwickelt sich weiter. Neben den bisherigen pac code-Befehlen gibt es eine neuere npm-basierte CLI, die diese künftig ablösen soll. Microsofts aktuelle Quickstarts arbeiten bereits mit den neuen Befehlen. Ein Migrationspfad ist dokumentiert. Wer heute startet, sollte diese Entwicklung kennen.
-
Lizenzen: Für diese Szenarien wird Power Apps Premium benötigt. Andere Lizenzformen reichen für diese Szenarien nicht. Premium kostet 20 USD pro User und Monat (12 USD ab 2'000 neuen User-Lizenzen) und berechtigt zum Bauen und Ausführen unbegrenzt vieler Apps. Für einen Machbarkeitsnachweis vorab gibt es den kostenlosen Developer Plan.
Fazit: Die spannende Entwicklung ist nicht React. Und auch nicht KI.
React konnten wir vorher schon. KI konnte vorher schon Code generieren. Und Low-Code konnte vorher schon Anwendungen bauen. Die eigentliche Veränderung passiert dazwischen. Klassische Entwicklung zieht in die Power Platform ein. Gleichzeitig verlässt Low-Code seine bisherigen Grenzen. Dadurch entsteht eine neue Architekturfrage. Nicht mehr: Low-Code oder Pro-Code? Sondern: Was wollen wir selbst bauen und was soll die Plattform für uns übernehmen? Das ist aus unserer Sicht die wirklich interessante Entwicklung. Denn eine interne Anwendung muss nicht mehr automatisch bei null anfangen.
Die Grenze verschwindet. Und damit wird nicht alles einfacher. Aber die Möglichkeiten werden deutlich besser.
