Dynamics 365 vs Power Apps Lizenz: Welche brauche ich wofür?

Die Frage, ob ein Anwender eine Dynamics-365-App-Lizenz oder eine reine Power-Apps-Lizenz braucht, entscheidet sich nicht an der App und nicht am Bildschirm, den der Nutzer sieht. Sie entscheidet sich an der Tabelle, in die geschrieben wird. Microsoft kennzeichnet einen kleinen Kreis von Tabellen als restricted: Wer in sie schreibt, benötigt eine Lizenz der zugehörigen Dynamics-365-App. Alles andere läuft mit Power Apps. Dieser Artikel zeigt, wie Sie diese Grenze im eigenen Projekt sauber ziehen und welche Power-Apps-Variante wann die richtige ist.

Das ist die technische Detailfrage unterhalb des großen Bildes. Den vollständigen Überblick über alle Lizenztypen liefert unser Dynamics-365-Lizenz-Guide; hier geht es gezielt um den Unterschied zwischen Dynamics-365-App und Power Apps.

Warum die Tabelle entscheidet, nicht die App

Dynamics 365 Sales, Customer Service, Field Service und Project Operations sind aus Sicht der Plattform nichts anderes als model-driven Apps auf Dataverse, ergänzt um Geschäftslogik und eine feste Datenstruktur. Genau diese Datenstruktur ist der Hebel für die Lizenzierung. Microsoft bindet die geschäftskritischen Tabellen dieser Produkte an die jeweilige Dynamics-365-Lizenz und nennt sie restricted Tables.

Der Grund ist zweigeteilt. Ein Teil dieser Tabellen speichert produktspezifische Konfigurationsdaten, die außerhalb der Anwendung keinen Sinn ergeben. Der andere Teil ist von fortgeschrittener Logik begleitet, die Daten auf eine bestimmte Weise erzeugt und pflegt, sobald sie innerhalb eines Dynamics-365-Produkts genutzt werden. Beides ist Teil dessen, wofür die Dynamics-365-Lizenz bezahlt wird.

Die praktische Konsequenz ist eindeutig: Sie können eine eigene Canvas- oder model-driven App bauen, die eine Opportunity anlegt. Technisch funktioniert das. Lizenzrechtlich braucht jeder Nutzer, der über diese App eine Opportunity anlegt, ändert oder löscht, eine Dynamics-365-Sales-Lizenz. Die schön gebaute eigene Oberfläche ändert daran nichts.

Wichtig ist auch, dass der App-Typ keine Rolle spielt. Ob der Zugriff über eine model-driven App, eine Canvas App, ein Power-Automate-Flow oder direkt über die Web API erfolgt, ist für die Lizenzfrage gleichgültig. Entscheidend ist allein, welche Operation auf welcher Tabelle ausgeführt wird. Damit lässt sich eine restricted Table auch nicht durch einen Umweg über einen Flow oder eine eigene Oberfläche umgehen; die Berechtigungslogik der Plattform prüft die Tabelle, nicht den Weg.

Non-restricted Tables: hier reicht Power Apps

Alle Standardtabellen von Dataverse, die nicht auf der Restricted-Liste stehen, sowie sämtliche selbst erstellten Tabellen sind uneingeschränkt nutzbar. Tabellen wie Account (Firma) und Contact (Kontakt) gehören dazu, ebenso Ihr eigenes Datenmodell für eine Fachanwendung. Für Anlegen, Lesen, Ändern und Löschen dieser Tabellen genügt eine Power-Apps-Lizenz. Sobald eine App allerdings einen Premium-Konnektor oder Dataverse nutzt, ist eine Power-Apps-Premium- oder Per-App-Lizenz Pflicht; die in Microsoft 365 enthaltenen Power-Apps-Rechte reichen dann nicht mehr.

Ein typisches Beispiel ist eine eigene Anwendung zur Angebotsverwaltung, die auf einer selbst erstellten Tabelle für Angebotspositionen aufsetzt und Firmen und Kontakte referenziert. So lange sie keine restricted Table beschreibt, laufen alle Nutzer mit einer Power-Apps-Lizenz, unabhängig davon, wie umfangreich die App wird oder wie viele eigene Tabellen sie umfasst.

Lesen ist nie lizenzpflichtig für Dynamics 365

Ein oft übersehener Punkt: Liest eine App oder ein Flow eine restricted Table nur aus, ist keine Dynamics-365-Lizenz nötig. Sie können also mit einer reinen Power-Apps-Lizenz ein Dashboard bauen, das offene Opportunities oder Fälle anzeigt, solange niemand über diese App schreibend eingreift. Erst das Anlegen, Ändern oder Löschen von Zeilen löst die Dynamics-365-Pflicht aus.

Welche Tabellen sind restricted?

Die Liste der eingeschränkten Tabellen pflegt Microsoft zentral. Sie ist überschaubar, aber sie enthält genau die Entitäten, um die sich reale Projekte drehen. Die folgende Auswahl zeigt die wichtigsten Vertreter und die dahinterstehende Dynamics-365-App.

Zwei Sonderfälle lohnen den Blick, weil sie in Self-Service-Szenarien immer wieder auftauchen. Für die Case-Tabelle dürfen Nutzer mit reiner Power-Apps-Lizenz Fälle anlegen sowie selbst angelegte Fälle lesen, ändern und löschen. Auf Fälle, die andere angelegt haben, haben sie nur Lesezugriff und dürfen nicht als Service-Agent agieren. Das deckt Employee-Self-Service ab, ersetzt aber keine Agenten-Lizenz. Ähnlich bei der Work-Order-Tabelle: Ein Mitarbeiter, der etwa einen Gebäudeschaden meldet, darf Work Orders mit Power-Apps-Lizenz anlegen und bearbeiten, aber keine Aufträge abschließen oder eine Serviceleistung erbringen.

Weil die Liste sich ändert, gehört ein Blick in die maßgebliche Quelle zu jeder Projektplanung. Microsoft führt alle eingeschränkten Tabellen samt Lizenzbedingung auf der Seite zu den Restricted Tables in Dataverse (Stand April 2026).

Power Apps Premium, Per App oder Pay-as-you-go

Steht fest, dass eine Power-Apps-Lizenz ausreicht, folgt die zweite Entscheidung: welche der drei Bezugsformen passt. Sie unterscheiden sich nicht im Funktionsumfang der Plattform, sondern im Abrechnungsmodell.

Die wichtigste Neuerung: Der Verkauf von Power Apps Per App wurde zum 2. Januar 2026 für Neukunden eingestellt. Bestehende Kunden über CSP können weiterhin kaufen, nutzen und verlängern; EA-Kunden, die Per App zu diesem Stichtag im Einsatz hatten, dürfen weiter verlängern. Für neue Vorhaben ist Per App damit faktisch keine Option mehr, die Wahl liegt zwischen Premium und Pay-as-you-go.

Wann Premium, wann Pay-as-you-go

Premium ist die richtige Wahl, wenn Sie eine bekannte, stabile Zahl regelmäßiger Nutzer haben. Die feste Monatsgebühr pro Nutzer ist planbar und deckt beliebig viele Apps ab. Pay-as-you-go spielt seine Stärke aus, wenn die Nutzung schwankt oder unbekannt ist: Es entstehen nur Kosten für Nutzer, die in einem Monat mindestens eine App in der Umgebung tatsächlich starten. Für einen Piloten, eine saisonale Anwendung oder eine App mit unklarer Adoption vermeidet das Fehlkäufe. Der Preis pro aktivem Nutzer liegt bei Pay-as-you-go allerdings über dem rechnerischen Premium-Preis, weshalb sich ab einer verlässlichen Nutzerbasis der Wechsel zu Premium lohnt. Wie Sie diese Modelle gezielt kombinieren, zeigt unser Beitrag zum Senken der Lizenzkosten.

Typische Fehlentscheidungen und Kostenfallen

In der Praxis wiederholen sich einige Muster, die entweder Geld kosten oder ein Projekt lizenzrechtlich angreifbar machen.

• Power-Apps-Lizenz auf restricted Tables geplant: Das Projekt kalkuliert mit günstigen Power-Apps-Lizenzen, obwohl das Datenmodell Opportunity, Case oder Work Order beschreibt. Die App läuft zunächst, die fehlende Berechtigung fällt aber spätestens im Lizenz-Audit auf und erzwingt eine Nachlizenzierung.
• Volle Dynamics-365-Lizenz für reine Datenerfasser: Der umgekehrte Fehler. Nutzer bekommen eine teure Dynamics-365-App-Lizenz, obwohl sie ausschließlich eigene Tabellen oder Account und Contact pflegen. Hier reicht Power Apps.
• Lesen mit Schreiben verwechselt: Ein reines Auswertungs-Dashboard auf Opportunities wird vorsichtshalber mit Dynamics-365-Lizenzen ausgestattet, obwohl Lesen keine solche Lizenz erfordert.
• Per App als Zukunftsplan: Neue Vorhaben planen mit Per App, das für Neukunden nicht mehr verfügbar ist. Die Architektur sollte von Beginn an auf Premium oder Pay-as-you-go ausgelegt sein.

Besonders heikel wird die Lage bei mehreren Dataverse-Instanzen und länderübergreifenden Rollouts, weil sich Nutzerzahlen und genutzte Tabellen je Region unterscheiden. Die Systematik dahinter behandelt unser Artikel zu Lizenzierungsstrategien für internationale Dynamics-Instanzen.

So gehen Sie die Entscheidung praktisch an

Die verlässlichste Methode ist, nicht von der geplanten App auszugehen, sondern vom Datenmodell. Listen Sie jede Tabelle auf, in die eine Nutzergruppe schreibend eingreift, und gleichen Sie sie mit der Restricted-Liste ab. Steht auch nur eine eingeschränkte Tabelle mit Schreibzugriff darauf, braucht diese Nutzergruppe die passende Dynamics-365-App-Lizenz. Bleiben nur Standard- und eigene Tabellen übrig, genügt Power Apps.

Danach segmentieren Sie die Nutzer nach ihrem realen Verhalten: reine Leser, Datenerfasser auf eigenen Tabellen, echte Dynamics-365-Anwender. Ein und dieselbe Person kann dabei je nach Aufgabe unterschiedlich einzustufen sein, was bei gemischten Rollen zu einer Kombination aus Dynamics-365- und Power-Apps-Lizenzen im selben Team führt. Prüfen Sie außerdem, ob eine kostengünstigere Dynamics-365-Rolle mit eingeschränkten Nutzungsrechten das reale Aufgabenprofil bereits abdeckt, bevor Sie zur vollen App-Lizenz greifen. Erst auf dieser Basis wählen Sie zwischen Premium und Pay-as-you-go. Diese Reihenfolge, erst die Tabelle, dann der Nutzer, dann das Abrechnungsmodell, verhindert die teuersten Fehlgriffe. Wenn Sie Ihr konkretes Datenmodell gegen die Lizenzlogik prüfen lassen wollen, sprechen Sie uns an. Wir bewerten Ihre Tabellen und Nutzergruppen und leiten daraus die kostenoptimale Lizenzstruktur ab.