Canvas Apps offline mit Dataverse: der neue Online-Modus und der FetchXML-Editor im Offline-Profil

Stell dir einen mittelständischen Anlagen- und Wartungsdienstleister vor. Die Techniker arbeiten dort, wo es weh tut: im Kellergeschoss einer Industriehalle, im ländlichen Umspannwerk, hinter dicken Betonwänden. Genau da, wo das Mobilfunknetz aufhört. Die Work Orders, Customer Assets, Buchungen, Checklisten und Fotos liegen in Dataverse — und die Canvas App auf dem Diensthandy soll trotzdem laufen, als wäre nichts. Und wenn der Techniker wieder aus dem Keller kommt, soll dieselbe App den Live-Lagerbestand ziehen, bevor er ein Ersatzteil einbaut.

Das ist kein Sonderwunsch mehr, sondern seit Mitte 2025 Standard-Funktionalität — mit einem wichtigen Zusatz, der 2026 in Preview kam. Dieser Artikel zeigt, was wirklich passiert, wenn eine Canvas App offline geht, und wie du sie so konfigurierst, dass sie im Einsatz hält.

Wer noch nicht sortiert hat, wo Canvas und Model-driven auseinandergehen, findet die Grundlagen in Was ist eigentlich eine Power App?.

1. Das Problem: Die App braucht Daten, das Gerät hat kein Netz

Der Techniker öffnet morgens die App, lädt seine Aufträge für heute, fährt zum Einsatzort — und verliert unterwegs die Verbindung. Ohne Offline-Fähigkeit sieht er ab dem ersten Funkloch nur noch Ladespinner und leere Galerien. Schreibt er einen Prüfbefund, ist er weg. Das ist der Regelfall in Wartung, Inspektion und Außendienst, nicht die Ausnahme.

2. Was man zuerst sieht

Aktivierst du Offline für eine Canvas App, wirkt zunächst alles wie vorher — nur schneller. Galerien laden ohne merkliche Latenz, auch im Keller. Der Haken: Das gilt nur im nativen Mobile Player (iOS, Android, Windows). Im Web-Browser ist eine Canvas App nie offline. Wer die App im Browser testet und sich wundert, warum “offline” nichts tut, sitzt genau in dieser Falle.

Die Gerätestatus-Seite im Power Apps Mobile Player: Synchronisierungsstatus „Bereit", letzter Sync-Zeitpunkt, heruntergeladene Daten (6 Tabellen) und lokaler Speicher — erreichbar über das Globus-Icon der offline-fähigen App

3. Was technisch wirklich passiert

Canvas-Offline arbeitet offline-first. Das ist der Punkt, an dem die meisten Missverständnisse anfangen:

Du definierst in einem Offline-Profil, welche Tabellen, Spalten und gefilterten Zeilen aufs Gerät gehören.
Diese Daten werden beim Sync in eine lokale SQLite-Datenbank auf dem Gerät kopiert.
Danach liest die App immer aus diesem Cache — auch mit bestem Netz. Schreibvorgänge landen zuerst lokal.
Sobald wieder Verbindung besteht, synchronisiert die App im Hintergrund.

Offline-first heißt also: Die App fragt Dataverse nicht live, sie fragt ihren lokalen Cache. Das ist schnell und robust, aber es bedeutet auch, dass der Nutzer standardmäßig nie den absolut aktuellen Serverstand sieht, sondern den Stand des letzten Down-Syncs.

Der Sync selbst ist differenziert:

Down-Sync läuft inkrementell nach einem Intervall, das du pro Tabelle festlegst (optimized delta sync: nur Änderungen; smart sync überspringt, wenn nichts passiert ist).
Up-Sync geht pro Spalte und sofort, sobald Netz da ist.
Konflikte werden nach last-write-per-column-wins aufgelöst — geschrieben wird spaltenweise zurück, deshalb scheitert ein Sync praktisch nie an einem Konflikt. Lehnt eine Server-Validierung die Änderung ab, gibt es einen lokalen Rollback und einen Eintrag in der Dataverse-Tabelle Sync Error.

Wichtig fürs Erwartungsmanagement: Die konfigurierbaren Conflict-Resolution-Settings im PPAC gelten nur für Model-driven, nicht für Canvas. Bei Canvas ist die Konfliktauflösung automatisch — du kannst sie nicht umstellen.

4. Die naheliegende, aber falsche Lösung

Der erste Reflex: Offline aktivieren, das Auto-Profil nehmen (das Power Apps automatisch anbietet) und fertig. Bei einem kleinen Datenmodell geht das durch. Bei unserem Wartungsdienstleister nicht.

Das Auto-Profil kennt keine Filter. Es lädt alle Zeilen, für die der Nutzer berechtigt ist. Bei einer Work-Order-Tabelle mit sechsstelliger Zeilenzahl bedeutet das: minutenlange Erst-Syncs, volllaufender Gerätespeicher und Sync-Timeouts. Faustregel: Ab etwa 15 Tabellen oder sobald du filtern musst, gehört ein eigenes (custom) Profil her.

5. Die belastbare Lösung

Das Offline-Profil sauber schneiden

Weg im Power Platform Admin Center: Umgebung > Einstellungen > Mobile-Konfiguration > Neues Profil erstellen (alternativ direkt im Power Apps Studio unter Einstellungen > Allgemein > „Kann offline verwendet werden”, sofern die App in einer Solution liegt). Im Profil legst du je Tabelle fest: welche Spalten, welche Beziehungen, welche Medien, welche Sync-Frequenz — und vor allem den Filter je Tabelle.

Für den Wartungsdienstleister heißt das konkret:

Customer Assets nur mit statecode = aktiv — stillgelegte Anlagen braucht niemand offline.
Buchungen nur die des eingeloggten Technikers (eq-userid) für heute und die nächsten sieben Tage.
Die Beziehungskette Work Order → Booking → Resource so schneiden, dass sie ins Limit passt (dazu unten).
Fotos über Bildspalten, aber sparsam (max. 14 Bildspalten insgesamt).

Offline-Profil-Editor im Power Platform Admin Center: das Profil „Wartung Außendienst" mit den Offline-Tabellen Firma und Aufgabe und ihren Filtern (Organisationszeilen)

Offline in der App einschalten

Das Profil allein reicht nicht — die App muss es auch nutzen. Zwei Dinge, die in der Praxis Zeit kosten:

Der Schalter „Kann offline verwendet werden” (Studio → Einstellungen > Allgemein) erscheint nur, wenn die App in einer Solution liegt. Fehlt er, ist das fast immer der Grund — leg die Canvas App in eine Solution, dann ist er da.
Unter „Offline-Profil auswählen” steht standardmäßig „Automatisch generiert”. Stell hier bewusst dein veröffentlichtes Custom-Profil ein (bei uns „Wartung Außendienst”) — ein Profil, das noch nicht veröffentlicht ist, taucht hier gar nicht auf.

Beim Einschalten fügt Power Apps automatisch einen Offline-Template-Bildschirm mit Globus-Icon ein. Dieses Icon öffnet die Gerätestatus-Seite (siehe oben) und spiegelt den Sync-Status per Farbe. Damit der Techniker es erreicht, gehört der Template-Bildschirm nach vorn (Startbildschirm) oder ein Globus-Control aufs Hauptformular. Zum Schluss: Speichern und Veröffentlichen — der Mobile Player lädt immer die veröffentlichte Version.

Ein ehrlicher Praxis-Befund am Rande: Mit „Automatisch generiert” lud die App im Test 0 Tabellen herunter — offline passierte schlicht nichts. Erst mit dem kuratierten, veröffentlichten Profil synchronisierte sie echte Daten (auf der Gerätestatus-Seite: 6 Tabellen, ~9 MB). Die Profilpflege ist also kein Nice-to-have, sondern die Voraussetzung dafür, dass offline überhaupt Daten da sind.

In den App-Einstellungen (Power Apps Studio → Einstellungen → Allgemein): „Kann offline verwendet werden" ist an, und im Dropdown „Offline-Profil auswählen" wird statt „Automatisch generiert" das veröffentlichte Profil „Wartung Außendienst" gewählt

Der FetchXML-Editor im Offline-Profil (Preview)

Hier kommt das Werkzeug, das große Tabellen erst zähmt. Statt nur über die Klick-Filter zu gehen, kannst du den Filter einer Tabelle direkt als FetchXML schreiben.

Preview / GA: Der FetchXML-Editor ist seit 17.03.2026 in Preview, GA ist für September 2026 geplant (planned/projected — kann sich verschieben). Nicht für kritische Produktivszenarien ohne Fallback einsetzen.

Weg dorthin: Offline Profiles > Profil > Edit profile > Tabelle wählen > Filter “Custom” oder “Related rows” > Edit filter > View/Edit FetchXML > Apply + Save.

Für unsere Buchungen des Technikers von heute könnte der Filter so aussehen:

<fetch>
  <entity name="bookableresourcebooking">
    <attribute name="bookableresourcebookingid" />
    <attribute name="name" />
    <attribute name="starttime" />
    <attribute name="bookingstatus" />
    <filter type="and">
      <condition attribute="starttime" operator="next-seven-days" />
      <condition attribute="ownerid" operator="eq-userid" />
    </filter>
    <link-entity name="msdyn_workorder" from="msdyn_workorderid" to="msdyn_workorder" link-type="any">
      <filter type="and">
        <condition attribute="statecode" operator="eq" value="0" />
      </filter>
    </link-entity>
  </entity>
</fetch>

Der Editor kann mehr als der Klick-Filter: hierarchische Bedingungen (under, eq-or-under …), Links zu unrelated Tables und latematerialize="true" für schwere Joins. Genau damit drückst du die Datenmenge, die aufs Gerät wandert, gegen null — der beste Schutz vor Sync-Timeouts bei Tabellen mit 100.000+ Zeilen.

Die Grenzen des Editors solltest du kennen, bevor du dich verrennst:

Maximal 500 Filter-Clauses pro Query.
Nur link-type="any" oder not any — kein inner/outer join.
page und count werden ignoriert.

Der neue Online-Modus (Preview)

Bisher galt: offline-fähig hieß immer Cache-Lesen, nie live. Das ändert sich 2026.

Preview / GA: “Enable online mode” ist in Preview, GA für September 2026 geplant.

Eine offline-fähige App kann jetzt zwischen Offline-Modus (liest aus dem Cache) und Online-Modus (liest live aus Dataverse, in Echtzeit) umschalten — ohne die Offline-Fähigkeit aufzugeben. Aktiviert wird das unter Settings > Online mode. Der Endnutzer schaltet dann selbst auf der Offline-Status-Seite um; die App merkt sich den zuletzt gewählten Modus.

Für den Wartungstechniker ist das der fehlende Baustein: Steht er beim Kunden vor dem Lager und will wissen, ob das Ersatzteil jetzt verfügbar ist, schaltet er auf Online-Modus und sieht den echten Live-Lagerbestand. Fährt er in die nächste Halle ohne Netz, arbeitet er offline weiter. Immer sinnvoll, wenn Datenaktualität kritisch ist — Inventur, Inspektion, Bestandsprüfung —, ohne die Offline-Sicherheit zu verlieren.

Push Notifications in wrapped Apps (Preview)

Für gebrandete (wrapped / white-label) Apps kommen Push Notifications dazu.

Preview / GA: Push in custom-branded Apps ist seit 08.05.2026 in Preview, GA September 2026 geplant. Bereits GA seit 23.04.2026: “Download wrapped apps directly from Dataverse”.

Der Toggle sitzt im Wrap-Wizard (Android + iOS). Die Mechanik läuft über Google Firebase (FCM): Firebase-Projekt und App registrieren, google-services.json bzw. .plist hochladen. Versendet wird über einen Power-Automate-Flow, dessen HTTP-Action Firebase bei einem Dataverse-Trigger anspricht (z. B. “neuer dringender Work Order zugewiesen”).

6. Diagnose- und Entscheidungscheckliste

Bevor du Canvas-Offline ausrollst, geh diese Punkte durch:

Läuft die App nativ? Nur Mobile Player (iOS/Android/Windows), niemals Browser. Standalone Canvas — nicht embedded, nicht Custom Pages, nicht Teams-Canvas.
Ist die Datenquelle Dataverse? Offline gilt nur für Dataverse. Kein SharePoint, SQL oder O365 offline (dafür nur das alte LoadData/SaveData im Speicher, ~30–70 MB, ohne automatische Konfliktlösung).
Passt das Datenvolumen? Max. 3.000.000 Zeilen gesamt synchronisierbar. Filtere aggressiv über das Profil (und FetchXML), weil offline keine Server-Delegation greift — die Query läuft gegen lokales SQLite.
Halten die Beziehungen die Limits? Max. 15 Beziehungen pro Tabelle im Profil, davon max. eine M:M oder 1:M, keine zirkulären, keine Self-Lookups. Lookup-Filter nur eine Ebene tief, keine M:M offline.
Bildspalten gezählt? Max. 14 Bildspalten über alle Entities.
Auto- oder Custom-Profil? Ab ~15 Tabellen oder sobald du filtern musst: Custom-Profil.
Brauchst du Live-Daten vor Ort? Dann Online-Modus einplanen (Preview).
Sync-Fehler überwacht? Die Dataverse-Tabelle Sync Error im Blick behalten und im Zweifel eine Status-Seite in die App bauen.

7. Die unbequemen Grenzen

Canvas-Offline ist gut geworden, aber es ist kein zweiter, vollständiger Client. Was nicht offline geht, musst du im Design von vornherein einplanen:

Flows laufen offline nicht. Was ein Flow erledigen soll, passiert erst nach dem Sync.
Calculated- und Rollup-Spalten werden am Client nicht neu berechnet — erst nach dem Sync auf dem Server. Zeig dem Nutzer keine “frischen” Summen vor, die es offline gar nicht gibt.
Power Fx Relate/Unrelate funktionieren offline nicht, M:M nicht, Notes nicht.
Virtual Tables und Elastic Tables sind offline außen vor.
Hintergrund-Sync läuft nur im Vordergrund bzw. bei entsperrtem Gerät — auf iOS ausschließlich im Foreground. Der Sync passiert nicht, während das Handy in der Jackentasche steckt.
Keine Server-Delegation offline. Alles, was du an Datenmenge nicht vorab über das Profil begrenzt hast, musst du lokal durchsuchen.

Canvas vs. Model-driven offline

Beide nutzen dieselbe Engine: Offline-Profile, SQLite, Delta-Sync, Sync-Error-Tabelle. Unterschiede:

Model-driven bringt die Device-Status-Seite out-of-the-box mit; bei Canvas baust du sie über das Offline-Template selbst ein.
Model-driven hat Conflict-Detection-Settings im PPAC — die für Canvas eben nicht gelten.
Model-driven ist insgesamt reifer. Canvas holt mit Online-Modus und FetchXML-Editor gerade auf.

Und eine ehrliche Randnotiz zur Planung: Die Release Plans werden ab September 2026 eingestellt, und die genannten GA-Termine (September 2026) sind “planned/projected” — sie können sich verschieben. Baue keine Produktiv-Roadmap auf ein Preview-Datum, ohne einen Fallback zu haben.

Siehe auch

Was ist eigentlich eine Power App? — Canvas vs. Model-driven, und wann Power Apps die falsche Wahl ist.
Das alte Grid ist abgekündigt — was das Power Apps grid control besser macht — Reflow/Card-List und Mobile-Verhalten im neuen Grid.
Git-Integration in Power Platform — Canvas Apps und Offline-Profile sauber versioniert im Repo.

Quellen: Microsoft Learn — mobile-offline-works-overview, canvas-mobile-offline-overview, limitations-canvas-apps, resolve-sync-conflicts, fetchxml-editor; Power Platform Release Wave 1 2026 (planned features); Power Platform Blog (Canvas-Offline GA, 11.06.2025). Preview- und GA-Angaben Stand August 2026; GA-Termine sind geplant und können sich verschieben.