Was ist eigentlich eine Power App?

„Das bauen wir schnell als Power App.” Diesen Satz hört man im DACH-Mittelstand täglich. Meistens ist er richtig. Die teuren Fehler entstehen nicht dabei, ob man Power Apps nimmt — sondern bei der Frage, welche der beiden Bauformen es wird. Und die wird erschreckend oft nach dem Aussehen entschieden.

Dieser Beitrag räumt damit auf: Was Canvas und Model-driven technisch wirklich unterscheidet, welche Grenze du als Erstes triffst, und wie du die Entscheidung so triffst, dass sie in zwei Jahren noch trägt.

1. Das Problem: Die Bauform wird als Startoption verkauft

Wer in make.powerapps.com eine App anlegt, sieht drei Einstiege: „Mit Entwurf beginnen”, „Mit Daten beginnen”, „Mit Plan beginnen”. Das klingt nach einer Frage des Vorgehens — und verdeckt, dass hier eine Architekturentscheidung fällt, die man später nur durch Neubau korrigiert.

Denn eine Canvas App lässt sich nicht in eine Model-driven App umwandeln. Und umgekehrt auch nicht. Es gibt keinen Migrationspfad, keinen Konverter, keinen Schalter. Wer sich vertut, baut neu.

Das typische Schadensbild sieht so aus: Ein Fachbereich baut eine Canvas App auf einer SharePoint-Liste, weil das schnell ging und keine zusätzliche Lizenz brauchte. Ein Jahr später sind es 4.000 Zeilen, die Suche liefert falsche Ergebnisse, und niemand versteht, warum — die App zeigt keinen Fehler.

2. Was man zuerst sieht: zwei Zeilen in derselben Liste

In der App-Übersicht stehen beide Bauformen nebeneinander, unterschieden nur durch eine Spalte Typ: „Canvas” oder „Modellgesteuert”. Optisch gleichwertig, technisch grundverschieden.

Der Unterschied ist nicht „frei gestaltbar gegen starr”. Er ist: Wo leben Daten, Logik und Berechtigungen?

• Canvas App: Die App bringt ihren eigenen Datenzugriff mit. Sie verbindet sich über Connectors mit einer oder mehreren Quellen — SharePoint, SQL, Dataverse, Excel, Web-APIs — und die Logik steht in Formeln auf den Steuerelementen. Die App ist das Zentrum, die Daten hängen dran.
• Model-driven App: Das Datenmodell in Dataverse ist das Zentrum. Formulare, Ansichten, Diagramme und Geschäftsregeln sind Eigenschaften der Tabelle, nicht der App. Die App ist im Wesentlichen eine Navigationshülle über diese Metadaten.

Das ist keine Metapher, das steht so im Tabellen-Designer. Öffne eine Dataverse-Tabelle, und du siehst „Schema” (Spalten, Beziehungen, Schlüssel) direkt neben „Datenerfahrungen” (Formulare, Ansichten, Diagramme, Dashboards) und „Anpassungen” (Geschäftsregeln, Befehle):

Wer diese eine Ansicht verstanden hat, versteht Model-driven: Die Oberfläche ist Metadatum der Tabelle. Baust du eine zweite App auf derselben Tabelle, erbt sie dieselben Formulare, dieselben Regeln, dieselben Berechtigungen. Bei Canvas baust du beides zweimal.

3. Was technisch wirklich passiert: Delegation

Der wichtigste technische Begriff für Canvas Apps heißt Delegation — und er entscheidet, ob deine App bei 400 Zeilen funktioniert und bei 4.000 stillschweigend falsche Ergebnisse liefert.

Eine Canvas App holt sich Daten nicht komplett ab. Sie versucht, Filter, Sortierung und Suche an die Datenquelle zu delegieren: Der Server rechnet, die App bekommt das Ergebnis. Kann die Quelle eine Funktion nicht verarbeiten, muss die App die Daten lokal auswerten — und zieht sich dafür nur so viele Zeilen, wie der Grenzwert erlaubt.

Diesen Grenzwert findest du in Canvas Studio unter Einstellungen → Allgemein:

Wörtlich: „Hiermit legen Sie fest, wie viele Zeilen aus serverbasierten Verbindungen abgerufen werden, wenn keine Delegierung unterstützt wird.” Der Standardwert ist 500.

Und hier liegt die Falle: Wenn deine Tabelle 4.000 Zeilen hat und du nicht-delegierbar filterst, arbeitet die App auf den ersten 500 — ohne Fehlermeldung. Das Ergebnis ist nicht leer, es ist falsch. Genau das macht den Fehler so teuer: Er sieht aus wie ein Datenproblem, nicht wie ein Architekturproblem.

Canvas Studio warnt beim Schreiben der Formel mit einem blauen Hinweis auf nicht delegierbare Ausdrücke. Diese Warnung wegzuklicken ist die häufigste Ursache für „die App zeigt nicht alle Datensätze”.

Was das für die Wahl der Datenquelle heißt: Wie weit Delegation trägt, hängt an der Quelle. Dataverse und SQL delegieren viel, SharePoint deutlich weniger, statische Quellen wie Excel praktisch nichts. Die Bauform allein rettet dich also nicht — die Quelle entscheidet mit.

Bei Model-driven Apps stellt sich die Frage nicht: Die Ansichten laufen serverseitig gegen Dataverse. Dafür hast du dort keine Wahl bei der Quelle — es ist Dataverse.

4. Die naheliegende falsche Entscheidung: nach Optik wählen

„Canvas sieht besser aus” ist der Satz, der die meisten Fehlentscheidungen einleitet. Er stimmt sogar — nur ist Optik selten das teure Kriterium.

Drei Varianten desselben Fehlers:

• Canvas gewählt, weil die Maske hübsch werden soll — und zwei Jahre später liegen Berechtigungslogik, Pflichtfelder und Validierung in Formeln verstreut über 30 Bildschirme, statt einmal am Datenmodell.
• SharePoint-Liste als Backend gewählt, weil sie „nichts kostet” — und dann kommt die Delegation. Nebenbei: Der Dataverse-Connector weist im Datenbereich explizit aus, dass die Nutzung einen Power Apps Premium-Plan, einen Pro-App-Plan oder einen Plan zur nutzungsbasierten Bezahlung voraussetzt. Diese Lizenzfrage gehört an den Anfang der Entscheidung, nicht ans Ende.
• Model-driven gewählt, weil „das ist das professionelle” — für ein Werkzeug, das im Kern aus einem Foto, zwei Feldern und einem Barcode-Scan besteht. Dafür ist Canvas gebaut.

5. Der belastbare Entscheidungspfad

Vier Fragen, in dieser Reihenfolge. Die erste, die eindeutig beantwortet werden kann, entscheidet.

Frage 1 — Wer nutzt die App? Externe ohne Microsoft-365-Konto? Dann ist es keine Power App, sondern ein Fall für Power Pages oder eine echte Web-Anwendung.

Frage 2 — Liegt der Wert im Prozess oder im Erlebnis? Prozess (Status, Zuständigkeit, Historie, Regeln, Berichte) → Model-driven. Erlebnis (ein Bildschirm, eine Aufgabe, Kamera, Standort, Offline) → Canvas.

Frage 3 — Wird das Datenmodell von mehreren Dingen genutzt? Wenn außer dieser App noch Flows, Berichte, ein Agent oder eine zweite App auf dieselben Daten sollen: Dataverse, und damit meist Model-driven. Der Grund ist die Wiederverwendung von Berechtigungen und Regeln, nicht die Optik.

Frage 4 — Wie viele Zeilen in zwei Jahren? Unter 500 ist die Delegation egal. Darüber wird sie zur Hauptfrage, und die Antwort heißt: delegierbare Quelle (Dataverse, SQL) und delegierbare Formeln.

Der Mischfall, der oft der richtige ist

Die Bauformen schließen sich nicht aus. Ein häufiges, tragfähiges Muster: Dataverse als Datenmodell, Model-driven für die Sachbearbeitung im Innendienst, eine schlanke Canvas App für den mobilen Sonderfall — beide auf denselben Tabellen, denselben Regeln, denselben Berechtigungen.

Genau dann zahlt sich Dataverse aus: Der Aufwand für das Datenmodell entsteht einmal und trägt beide Apps. Wie weit das mobil trägt — inklusive Offline —, steht in Canvas Apps offline mit Dataverse; der Schalter „Kann offline verwendet werden” im Screenshot oben sagt es schon: nur Dataverse.

6. Entscheidungs-Checkliste

• Zielgruppe geklärt — interne Konten, oder braucht es Power Pages?
• Bauform bewusst gewählt (Prozess → Model-driven, Aufgabe/Mobil → Canvas), nicht nach Optik
• Datenquelle bewusst gewählt; Lizenzbedarf für Dataverse/Premium-Connectors vorher geklärt
• Erwartetes Datenvolumen in 2 Jahren geschätzt; über 500 Zeilen: Delegierbarkeit geprüft
• „Grenzwert für Datenzeilen” bewusst gesetzt (Standard 500) — und verstanden, dass er ein Notnagel ist, keine Lösung
• Keine Delegierungswarnung in den Formeln ignoriert
• Offline-Bedarf geklärt (geht nur mit Dataverse und nur im nativen Mobile Player)
• Umgebungen Dev/Test/Prod aufgesetzt, bevor die erste App gebaut wird
• Solution + Publisher-Präfix von Anfang an, nicht nachträglich
• Connection References statt persönlicher Verbindungen
• Klar, wem die App gehört, wenn die Person das Unternehmen verlässt

7. Grenzen — wo du nicht drüber hinweggehen solltest

• Keine Umwandlung zwischen den Bauformen. Falsch entschieden heißt neu bauen.
• Delegation scheitert leise. Kein Fehler, nur falsche Ergebnisse. Das ist die unangenehmste Eigenschaft der Plattform.
• Model-driven bedeutet Dataverse. Damit kommen Lizenzkosten und Kapazitätsverbrauch — beides gehört vor die Entscheidung, nicht danach.
• Pixelgenaue Markenauftritte sind mit Model-driven nicht vorgesehen und mit Canvas Handarbeit. Für ein Produkt mit tausenden externen Anwendern ist beides die falsche Wahl.
• Low-Code heißt nicht wartungsfrei. Ohne Umgebungen, Solutions und ALM stehen nach einem Jahr 300 Apps da, und niemand weiß, welche produktiv sind. Der Weg dahin steht in Git-first mit Dataverse-Environments im Team.

Faustregel: Power Apps löst das spezifische Problem eines Teams hervorragend. Es ist kein Ersatz für ein Produkt mit tausenden externen Anwendern.

Stand: August 2026. Screenshots und Werte (Grenzwert 500, Offline-Schalter, Lizenzhinweis am Dataverse-Connector) stammen aus einem eigenen Durchlauf in make.powerapps.com am 29. August 2026. Die Delegierungswarnung im Formel-Editor ist beschrieben, aber nicht abgebildet — sie ließ sich in diesem Durchlauf nicht sauber einfangen.

Siehe auch

• Canvas Apps offline mit Dataverse — was Canvas mobil wirklich kann, und warum Offline an Dataverse hängt.
• Das alte Grid ist abgekündigt — wie die Listenansicht in Model-driven Apps heute aussieht.
• Git-first mit Dataverse-Environments im Team — Umgebungen, Solutions und Freigaben, bevor Wildwuchs entsteht.
• Der Flow ist deployt – und trotzdem aus — warum Verbindungen nie mit der Solution mitreisen.
• Prompt Columns in Dataverse — was das Datenmodell zusätzlich kann, wenn es einmal in Dataverse liegt.