Power Platform in der Verwaltung: SharePoint-Listen oder Dataverse für Fachanwendungen?

Es beginnt immer gleich. Im Organisationsamt sitzt jemand, der es einfach leid ist, den Besprechungsraum im Erdgeschoss per Zuruf zu verwalten. Zwei Nachmittage später gibt es eine Power App. Sie funktioniert. Sie sieht sogar gut aus. Und sie liegt in einer SharePoint-Liste, von der niemand in der IT weiß, in einem Environment, das „Contoso (default)“ heißt und für das sich formal niemand als Administrator eingetragen hat.

Das ist keine Katastrophe. Das ist der Normalfall, und in vier von fünf Fällen ist es genau die richtige Lösung. Der Ärger entsteht erst, wenn die fünfte Anwendung dazukommt — und in dieser fünften stehen Namen von Menschen, die einen Antrag nach dem SGB XII gestellt haben. Ab da geht es nicht mehr um Bequemlichkeit, sondern um die Frage, wer welchen Datensatz sehen darf. Und diese Frage entscheidet, ob eine SharePoint-Liste ausreicht oder ob Sie Dataverse brauchen.

Dieser Beitrag beantwortet drei Dinge: wann eine SharePoint-Liste vollkommen genügt, wann Dataverse unvermeidlich wird, und welche Lizenz- und Betriebsfolgen der Wechsel auslöst — Folgen, die typischerweise nicht die IT-Leitung trifft, sondern die Kämmerei, ein halbes Jahr später, in Form einer Rechnung, die niemand eingeplant hat.

Er ist Teil einer größeren Serie. Wenn Sie die grundsätzlichen Entscheidungen noch vor sich haben — Betriebsmodell, Schutzbedarf, Lizenzen, Vergabe — beginnen Sie besser bei der Übersicht Microsoft 365 in der öffentlichen Verwaltung. Dort finden Sie die Reihenfolge, in der die Themen sinnvoll abgearbeitet werden. Hier steigen wir mitten in den Maschinenraum ein.

FAKTENCHECK · Was Sie hier nicht bekommen Keine Rechtsberatung. Wertgrenzen, Fristen und Paragraphen tauchen in diesem Beitrag nur als Orientierung auf; maßgeblich ist immer das Recht Ihres Landes und die Auslegung Ihrer eigenen Rechtsabteilung. Auch die Frage, wann eine Anwendung aktenrelevantes Schriftgut erzeugt, entscheidet nicht Microsoft, sondern das Landes-E-Government-Recht in Verbindung mit Ihrem Aktenplan. Und keine Produktschelte. SharePoint-Listen sind nicht das billige Provisorium und Dataverse nicht die seriöse Lösung. Es sind zwei Werkzeuge mit unterschiedlichem Zuschnitt. Das eine falsch gewählt kostet Geld, das andere falsch gewählt kostet Vertrauen.

 

Die Vorfrage: Wer darf welchen Datensatz sehen?

Wenn eine Verwaltung sich zwischen SharePoint-Liste und Dataverse entscheidet, wird meistens über Datenmengen diskutiert. Das ist verständlich und fast immer falsch. Die Datenmenge ist selten das Problem. Das Problem ist die Berechtigung.

SharePoint denkt in Behältern. Eine Website hat Besitzer, Mitglieder und Besucher, und was in der Website liegt, erbt diese Rechte. Das passt hervorragend zu der Art, wie Verwaltungen Zusammenarbeit organisieren: Das Amt hat einen Raum, im Raum liegen die Unterlagen, wer im Amt ist, sieht sie. Genau dieses Denken haben wir in der Informationsarchitektur beschrieben, die einer Teams-Einführung zugrunde liegt.

Wer bei der Struktur noch am Anfang steht, findet die Systematik in Microsoft Teams in der Verwaltung einführen: Informationsarchitektur entlang der Ämter. Für Fachanwendungen gilt dieselbe Logik — nur reicht sie irgendwann nicht mehr.

Der Punkt, an dem das Behältermodell bricht

Nehmen Sie ein Fundbüro. Alle Fundsachen liegen in einer Liste, alle Beschäftigten des Bürgerbüros dürfen alle Einträge sehen. Behältermodell, passt, fertig.

Jetzt nehmen Sie eine Anwendung, in der Anträge auf wirtschaftliche Jugendhilfe erfasst werden. Die zuständige Sachbearbeitung soll ihre Fälle sehen. Die Amtsleitung soll die Fälle des Amtes sehen. Die Kollegin aus dem Nachbarbezirk soll den Fall nur sehen, wenn er ihr zugewiesen wurde. Und die Registratur soll gar nichts sehen außer dem Aktenzeichen. Das ist keine exotische Anforderung, das ist Verwaltungsalltag. Und es ist genau der Punkt, an dem SharePoint-Listen von einer eleganten Lösung zu einem Berechtigungs-Basteltisch werden.

Technisch geht es. Sie können in SharePoint die Vererbung pro Element brechen und jedem Datensatz eigene Rechte geben. Sie können das per Flow automatisieren. Es gibt Verwaltungen, die genau das gemacht haben — und anderthalb Jahre später nach der Ursache dafür suchen, warum die Liste morgens vier Sekunden zum Laden braucht.

WARNUNG · Eindeutige Berechtigungen sind keine Architektur Microsoft nennt für eine SharePoint-Liste oder -Bibliothek eine unterstützte Obergrenze von 50.000 eindeutigen Berechtigungen — empfiehlt aber ausdrücklich, unter 5.000 zu bleiben. Ab 100.000 Elementen in einer Liste lässt sich die Vererbung auf Listenebene gar nicht mehr brechen oder wiederherstellen. Übersetzt in Verwaltungssprache: Ein Fundbüro mit 3.000 Einträgen pro Jahr, in dem jeder Eintrag eine eigene Berechtigung bekommt, steht nach zwei Jahren an der Empfehlungsgrenze. Danach wird nicht abgeschaltet — es wird nur langsam, unübersichtlich und im Störungsfall nicht mehr erklärbar.

 

Vier Fragen, die die Entscheidung tragen

Es gibt eine kurze Prüfung, die in der Praxis erstaunlich zuverlässig funktioniert. Vier Fragen, und ein einziges „ja“ genügt, um Dataverse ernsthaft zu prüfen.

Skizze 1: Die Entscheidungsweiche vor jeder Fachanwendung. Vier Mal „nein“ heißt: Liste. Ein „ja“ heißt: rechnen.

SharePoint-Liste und Dataverse im direkten Vergleich

Jetzt die Zahlen. Nicht weil Zahlen die Entscheidung ersetzen, sondern weil in Beschlussvorlagen erfahrungsgemäß nicht das Gefühl gewinnt, sondern die Tabelle.

Kriterium	SharePoint-Liste	Dataverse
Berechtigung auf Datensatzebene	Nur über eindeutige Berechtigungen pro Element; empfohlene Obergrenze 5.000, unterstützt 50.000. Wartungsaufwand steigt mit jedem Datensatz.	Kernfähigkeit. Sicherheitsrollen, Geschäftseinheiten, Teams, Datensatzeigentümer, zusätzlich einzelne Freigabe. Kein Klickwerk pro Zeile.
Berechtigung auf Feldebene	Nicht vorgesehen. Sichtbarkeit einzelner Spalten ist Oberflächenkosmetik, keine Sicherheit.	Spaltensicherheit als eigenes Konzept. Das Feld „Bankverbindung“ kann für die halbe Belegschaft schlicht nicht existieren.
Mengengerüst	Bis 30 Millionen Elemente möglich; ab 100.000 Elementen gelten Sonderregeln, Filter ohne Index laufen gegen die Listenansichtsschwelle von 5.000.	Keine dokumentierte Zeilengrenze. Begrenzt wird über gekaufte Datenbankkapazität, nicht über Tabellenmechanik.
Relationen	Nachschlagespalten funktionieren, mehr als zwei Ebenen werden zäh. Für „Antrag › Vorgang › Teilleistung“ ungeeignet.	Echtes relationales Modell mit referenzieller Integrität, Kaskadenverhalten und berechneten Feldern.
Delegierung in Power Apps	Eingeschränkter Funktionsumfang. Was nicht delegiert wird, holt die App als erste 500 Datensätze (auf 2.000 erhöhbar) — mit still falschen Ergebnissen.	Breitester Delegierungsumfang aller Datenquellen. Anfragen laufen ohne Umweg über die API-Verwaltung, dadurch spürbar schneller.
Änderungshistorie	Versionsverlauf der Elemente. Für die Frage „wer hat wann welchen Wert geändert“ mühsam auswertbar.	Auditierung als Serverfunktion, pro Tabelle und Spalte konfigurierbar. Das ist die Form, in der Rechnungsprüfung Nachweise erwartet.
Geschäftslogik	Power-Automate-Flows und Formelfelder. Logik liegt in der App — wer die App umgeht, umgeht die Logik.	Geschäftsregeln und serverseitige Erweiterungen. Die Regel gilt unabhängig davon, wer schreibt.
Lizenzbedarf der Nutzer	Nutzungsrechte aus Microsoft 365 E3/E5/F3 genügen, solange nur Standard-Connectoren im Spiel sind.	Premium-Fähigkeit. Jeder Nutzer braucht Power Apps Premium oder ein gleichwertiges Recht.
Trennung von Entwicklung und Betrieb	Möglich, aber unbequem: Listen werden kopiert, Verweise laufen ins Leere.	Lösungen, Umgebungsvariablen, Verbindungsverweise. DEV › TEST › PROD ist der vorgesehene Weg, nicht der Ausnahmefall.
Sicherung und Wiederherstellung	Papierkorb und Aufbewahrungsrichtlinien; die Wiederherstellung einer einzelnen Liste in definiertem Zustand ist keine Ein-Klick-Sache.	Systemsicherungen und wiederherstellbare Environments; Sandbox-Environments lassen sich kopieren und zurücksetzen.
Wer kann es betreiben	Die Fachämter, mit Rückendeckung der IT. Sehr niedrige Einstiegshürde.	Braucht eine benannte Rolle, die Sicherheitsrollen versteht. Ohne diese Rolle wird Dataverse zur Blackbox mit Rechnung.

 

Die harten Grenzen von SharePoint, in Zahlen

Damit Sie in der Diskussion mit dem Fachamt belastbar bleiben, hier die Werte, die tatsächlich weh tun — nicht die theoretischen Maxima:

Listenansichtsschwelle: 5.000. Wer über nicht indizierte Spalten filtert oder sortiert, bekommt oberhalb dieser Grenze Fehler statt Ergebnisse.

Eindeutige Berechtigungen: 5.000 empfohlen, 50.000 unterstützt. Der Unterschied zwischen beiden Zahlen ist die Grauzone, in der Verwaltungen leben, ohne es zu wissen.

Vererbungsbruch auf Listenebene: ab 100.000 Elementen nicht mehr möglich.

Anlage an einem Listenelement: 250 MB. Für einen eingescannten Bauantrag reicht das; als Dokumentenablage ist eine Liste dennoch die falsche Wahl.

Delegierungsgrenze in Power Apps: 500 Datensätze im Standard, auf 2.000 erhöhbar. Alles darüber wird lokal verarbeitet — und still unvollständig.

WICHTIG · Die 500 sind der teuerste Wert in diesem Beitrag Wenn eine Power-Fx-Formel nicht an die Datenquelle delegiert werden kann, holt Power Apps die ersten 500 Datensätze und rechnet lokal weiter. Es gibt eine Warnung im Erstellungswerkzeug, aber keine Fehlermeldung im Betrieb. Die App liefert einfach ein Ergebnis. Nur eben nicht das richtige. Für eine Raumbuchung mit 40 Räumen ist das irrelevant. Für eine Gebührenübersicht, aus der eine Summe in eine Vorlage für den Hauptausschuss wandert, ist es ein Prüfungsbefund. Microsoft empfiehlt für Tests, die Grenze bewusst auf 1 zu setzen — dann fällt jede nicht delegierte Abfrage sofort auf.

 

Zwei Berechtigungsmodelle, nebeneinandergelegt

Der Unterschied lässt sich in einem Bild fassen. Links das Behältermodell von SharePoint, rechts das Modell von Dataverse, das der Aufbauorganisation einer Verwaltung verblüffend nahe kommt: Organisation, Geschäftseinheit, Team, Datensatz, Feld. Wer Ämter, Abteilungen und Sachgebiete gewohnt ist, muss dieses Modell nicht lernen, sondern nur übersetzen.

Skizze 2: Vererbung von oben gegen Rolle-trifft-Geschäftseinheit. Rechts ist mehr Arbeit — einmal. Links ist weniger Arbeit — jeden Tag.

Ein Nebeneffekt, der in Verwaltungen unterschätzt wird: Eine saubere Rechtestruktur in Dataverse ist zugleich die beste Vorsorge gegen Übersichtsverlust bei Freigaben. Wer sich mit den Folgen zu großzügiger Rechte im Tenant schon beschäftigt hat, kennt das Muster.

Der Zusammenhang ist im Beitrag Oversharing im Verwaltungs-Tenant: Warum Copilot die Personalakte findet ausführlich beschrieben — und er gilt für Fachanwendungen genauso wie für Dokumentenbibliotheken. Eine SharePoint-Liste mit Sozialdaten und offener Websiteberechtigung ist genau die Art von Fund, den niemand machen möchte.

Environments: die Default-Environment-Falle und ein Zuschnitt, der trägt

Jetzt kommt der Teil, der in fast jeder Verwaltung schiefläuft, weil niemand ihn bewusst entschieden hat. Environments sind keine Ordner. Sie sind Sicherheits-, Daten- und Betriebsgrenzen. Eine App in einem Environment kann nur auf Datenquellen zugreifen, die im selben Environment bereitgestellt sind. Wer das ignoriert, baut sich einen Tenant, in dem alles überall liegt.

Was das Default-Environment wirklich ist

Jeder Tenant bekommt automatisch ein Default-Environment. Es heißt „{Tenantname} (default)“, liegt in der Heimatregion des Tenants und hat Eigenschaften, die man kennen sollte, bevor die erste Fachanwendung darin landet:

Jeder Nutzer, der sich für Power Apps anmeldet, wird automatisch der Maker-Rolle hinzugefügt. Jeder. Ohne Antrag, ohne Freigabe.

Es wird kein Nutzer automatisch Environment-Administrator. Auch Microsoft-365-und Power-Platform-Administratoren erhalten die Dataverse-Systemadministrator-Rolle im Default-Environment nicht mehr automatisch.

Microsoft bezeichnet es ausdrücklich als Umgebung für Erprobung und leichte Versuche — ohne Sicherungszusage und nicht für Produktivlasten.

Sie können es nicht löschen und nicht manuell sichern. Systemsicherungen laufen fortlaufend, mehr Zusage gibt es nicht.

Enthalten sind 3 GB Datenbank-, 3 GB Datei- und 1 GB Protokollkapazität; die Obergrenze liegt bei 1 TB Speicher.

WARNUNG · Der Fall des einen Admins — jetzt auch für Environments Es gibt Verwaltungen, in denen das Default-Environment über Jahre gewachsen ist, ein Dutzend Anwendungen enthält und niemand die Systemadministrator-Rolle hat. Das ist keine theoretische Gefahr: Microsoft empfiehlt selbst, die Rolle einigen vertrauenswürdigen Personen zuzuweisen, gerade um eine administrative Aussperrung zu vermeiden. Prüfen Sie das heute. Es dauert fünf Minuten und ist genau die Art von Befund, die im nächsten Prüfbericht sonst als Organisationsverschulden formuliert wird.

 

Wie man solche Rollen sauber aufsetzt, statt sie zu vergeben und zu vergessen, steht in Privilegierte Konten in der Verwaltungs-IT: Rollen, PIM und der Fall des einen Admins.

Ein Zuschnitt, der zur Verwaltung passt

Sie brauchen keine zwanzig Environments. Sie brauchen drei bis vier, mit klaren Zusagen. Die folgende Skizze zeigt den Aufbau, der sich in Verwaltungen mittlerer Größe bewährt hat — vom Amt bis zur externen Beteiligung.

Skizze 3: Environment-Aufbau. Das Default-Environment bleibt bewusst rot: erlaubt, aber ohne Betriebszusage.

Environment	Zweck	Wer darf hinein	Betriebszusage
Persönliche Produktivität (Default)	Versuche, Einzelplatzlösungen, Prototypen	Alle lizenzierten Nutzer sind automatisch Erbauer	Keine. Umbenennen, Freigabe drosseln, restriktive DLP-Richtlinie, regelmäßig aufräumen
Fachanwendungen DEV	Bauen und Ändern von Anwendungen mit Fachbezug	Benannte Erbauer aus IT und Fachämtern	Keine Fachdaten, nur Testdaten. Lösungen unmanaged
Fachanwendungen TEST	Abnahme durch das Fachamt, Barrierefreiheitsprüfung, Datenschutzprüfung	Fachamt, Datenschutz, Personalrat auf Anforderung	Kopie aus DEV, anonymisierte Daten, Freigabeprotokoll
Fachanwendungen PROD	Betrieb	Niemand baut hier. Zugriff über Sicherheitsgruppen je Amt	Sicherung, Audit-Log, mindestens zwei Systemadministratoren, Änderungen nur über Lösungen
Externe Beteiligung	Formulare und Anwendungen mit Beteiligung Dritter	Gäste nach eigenen Regeln	Eigene DLP-Richtlinie, engere Datenaufbewahrung, getrennte Prüfung

 

Wer Gäste in die Betrachtung einbezieht, sollte das nicht nebenbei regeln. Planungsbüros, freie Träger und Gremienmitglieder brauchen Zugriff, aber nicht denselben.

Die Mechanik dazu steht in Gäste in Teams und SharePoint: Planungsbüros, Träger und Gremienmitglieder sicher einbinden. Für Dataverse gilt zusätzlich, dass Gäste über Entra-B2B im Verzeichnis vorhanden sein müssen — ein anonymer Formularzugriff von außen ist ein anderer Bauplan.

Environment-Gruppen, Routing und der Rest der Leitplanken

Damit dieser Zuschnitt nicht nach sechs Monaten wieder zerfällt, gibt es drei Werkzeuge, die zusammen den Governance-Rahmen bilden — ohne dass Sie eine eigene Stelle dafür schaffen müssen.

Environment-Gruppen: Regeln wie Freigabegrenzen, Lösungsprüfung, Datenaufbewahrung und KI-Funktionen werden einmal für die Gruppe gesetzt und gelten für alle Environments darin. Voraussetzung ist, dass die Environments verwaltete Environments sind.

Environment-Routing: Neue Erbauer landen nicht im Default-Environment, sondern bekommen automatisch ein eigenes Developer-Environment, das optional direkt einer Gruppe zugeordnet wird. Das ist die eleganteste Antwort auf die Default-Environment-Falle, die Microsoft anbietet.

Richtlinien zur Datenverlustvermeidung: Welche Connectoren in welchem Environment erlaubt sind. Hier entscheidet sich, ob Fachdaten den Weg in einen privaten Speicherdienst finden — nicht in der Schulung, sondern in der Richtlinie.

Erstellung von Environments auf Administratoren beschränken. Sonst legt jeder mit Lizenz und 1 GB freier Kapazität ein Produktions-Environment an.

TIPP · Die Aufräumliste, die niemand führt Das Power Platform Admin Center liefert Empfehlungen zu Apps ohne gültigen Eigentümer und zu Apps, die in den letzten 60 Tagen nicht genutzt wurden. Beides ist in Verwaltungen Gold wert: Der eigentümerlose Fall entsteht regelmäßig, wenn jemand in Ruhestand geht oder das Amt wechselt. Setzen Sie eine halbe Stunde im Monat an. Eine Person, eine Liste, zwei Fragen: Gibt es einen Eigentümer, und wird es benutzt? Was beides mit „nein“ beantwortet wird, wird archiviert und abgeschaltet. Nach einem Jahr haben Sie ein Inventar, das dem Rechnungsprüfungsamt vorzeigbar ist.

 

Wenn Sie beim Thema Nachweise gerade sind: Welche Protokolle Verwaltungen tatsächlich liefern müssen und wie lange sie verfügbar sind, behandelt Microsoft 365 Audit-Log und Rechnungsprüfung: Nachweise, die Verwaltungen liefern müssen. Für Dataverse kommt die Auditierung der Plattform hinzu — und die ist der Grund, warum manche Fachanwendung überhaupt nach Dataverse gehört.

Lizenzfolgen: die Rechnung, die später kommt

Hier trennt sich die technische von der haushaltsrechtlichen Diskussion. Die Entscheidung für Dataverse ist keine Architekturentscheidung, sondern eine Entscheidung über wiederkehrende Ausgaben. Und sie hat die unangenehme Eigenschaft, sich zu vervielfachen.

Skizze 4: Die Lizenzkaskade. Von links nach rechts nimmt die Zahl der lizenzpflichtigen Personen zu, nicht die Zahl der Funktionen.

Stufe 0: Was in Microsoft 365 schon enthalten ist

Bestimmte Microsoft-365-Lizenzen enthalten eingeschränkte Nutzungsrechte für Power Apps und Power Automate. Microsoft formuliert den Zweck klar: für Szenarien, die Microsoft-365-Daten und Standard-Connectoren nutzen. Eine Power App auf einer SharePoint-Liste fällt genau darunter. Kosten: keine zusätzlichen.

Wichtig ist eine Feinheit, über die regelmäßig gestritten wird: Im Microsoft-365-Administrationsportal kann für solche Lizenzen ein Dienstplan „Dataverse“ auftauchen. Das bedeutet nicht, dass Sie damit eigene Anwendungen auf Dataverse betreiben dürfen. Diese eingeschränkten Rechte existieren für Funktionen, die eine Microsoft-365-Anwendung selbst benötigt — nicht für Ihre Fachanwendung.

Stufe 1: Dataverse ist eine Premium-Fähigkeit

Sobald Ihre Anwendung Dataverse oder einen Premium-Connector nutzt, braucht jeder Nutzer, der die App aufruft, ein entsprechendes Recht — Power Apps Premium oder eine gleichwertige Dynamics-365-Lizenz. Nicht nur der Erbauer. Jeder.

Rechnen Sie das einmal für einen realistischen Fall durch: Eine Raumbuchung, die alle 900 Beschäftigten einer Stadtverwaltung nutzen. Auf SharePoint: enthalten. Auf Dataverse: 900 Premium-Lizenzen. Das ist der gesamte Unterschied, und er hat nichts mit Technik zu tun.

Konstellation	Lizenzbedarf	Typische Verwaltungsfälle
Power App auf SharePoint-Liste, nur Standard-Connectoren	Nutzungsrechte aus Microsoft 365 E3/E5/F3	Raumbuchung, Fundbüro, Bestellliste des Bauhofs, Materialanforderung
Power App auf Dataverse	Power Apps Premium je Nutzer oder gleichwertiges Recht	Fallbearbeitung mit Zugriffsbeschränkung, Gebührenverwaltung mit Historie
Anwendung in einem verwalteten Environment	Alle aktiven Nutzer des Environments premiumlizenziert	Jedes Environment, das in einer Environment-Gruppe geführt wird
Nutzungsabhängige Abrechnung	Pay-as-you-go über eine Azure-Subskription, Abrechnung nach Verbrauch	Anwendungen mit schwer planbarer Nutzerzahl, Pilotphasen
Entwicklung und Test	Power Apps Developer Plan, kostenfrei, nur für Entwicklung und Test	Vorstudien, Machbarkeitsnachweise — ausdrücklich nicht für den Betrieb

 

Stufe 2: Managed Environments und die Kettenreaktion

Verwaltete Environments sind das Werkzeug, mit dem Sie Freigabegrenzen setzen, Lösungsprüfungen erzwingen und Environment-Gruppen überhaupt nutzen können. Governance-seitig ist das die richtige Wahl. Lizenzseitig hat sie einen Haken, den man kennen muss: Jeder Nutzer, der in einem verwalteten Environment eine App ausführt oder einen Cloud-Flow nutzt, benötigt eine Premium-Lizenz.

Das ist kein Kleingedrucktes, sondern der Kern der Kalkulation. Wenn Sie die Raumbuchung für alle in ein verwaltetes Environment legen, weil das sauberer aussieht, haben Sie damit die Lizenzpflicht für alle ausgelöst — auch wenn die Anwendung selbst auf einer SharePoint-Liste läuft. Deshalb gehört die schlichte Liste ins nicht verwaltete Umfeld, und Dataverse gehört in die verwaltete Gruppe. Die Trennlinie ist keine Geschmacksfrage.

WICHTIG · Per-App-Lizenz: nicht mehr der bequeme Ausweg Die Power-Apps-per-App-Lizenz war jahrelang das Mittel, um eine einzelne Fachanwendung mit Dataverse für einen begrenzten Nutzerkreis wirtschaftlich zu betreiben. Zum 2. Januar 2026 ist diese SKU über bestimmte Beschaffungswege für Neukunden nicht mehr verfügbar; die Verfügbarkeit für Bestandskunden und über Cloud-Solution-Provider unterscheidet sich. Wenn Ihre Kalkulation aus dem Jahr 2024 auf per-App aufsetzt, ist sie zu prüfen. Und wenn eine Leistungsbeschreibung diese Lizenz als Grundlage nennt, ist das ein Vergaberisiko, das Sie vor der Veröffentlichung ausräumen wollen.

 

Wie man Lizenzstände in Verwaltungen belastbar aufstellt, einschließlich der Behördenkonditionen, behandelt Microsoft 365 Lizenzen für Verwaltungen: E3, E5, F3 und die Behördenkonditionen. Für die Frage, wie eine Leistungsbeschreibung aussehen muss, die Power-Platform-Lizenzen nicht in die falsche Richtung festschreibt, lohnt der Blick in Microsoft 365 rechtssicher beschaffen: Vergabe, Leistungsbeschreibung, Rahmenverträge. Wertgrenzen und Verfahrensarten richten sich nach dem Recht Ihres Landes; die dortigen Angaben sind Orientierung, keine Rechtsauskunft.

Stufe 3: Kapazität ist ein eigener Topf

Dataverse-Speicher zerfällt in drei getrennte Kapazitäten: Datenbank, Datei und Protokoll. Sie sind nicht beliebig gegeneinander verrechenbar — unbenutzte Datenbankkapazität kann Protokoll- und Dateiüberschreitungen ausgleichen, aber nicht umgekehrt. Und jedes Environment belegt mindestens 1 GB, auch wenn es gar keine Datenbank enthält.

Praktische Folge für den Zuschnitt: Zwölf Environments „für Übersichtlichkeit“ kosten zwölf Gigabyte, bevor die erste Zeile Daten geschrieben ist. Und die Auditierung, die Sie für das Rechnungsprüfungsamt einschalten, schreibt in die Protokollkapazität — die üblicherweise der kleinste der drei Töpfe ist.

FAKTENCHECK · Was nicht auf die Kapazität zählt Trial-, Vorschau-, Support- und Developer-Environments sowie Dataverse-for-Teams-Environments zählen nicht gegen die Tenantkapazität. Nur Default-, Produktions- und Sandbox-Environments tun das. Das ist praktisch — und gleichzeitig der Grund, warum Developer-Environments einzelner Personen zum bevorzugten Entstehungsort inoffizieller Fachanwendungen werden. Sie sind gratis, unsichtbar in der Kapazitätsübersicht und laufen so lange, wie die Person aktiv bleibt.

 

Drei Fälle aus der Verwaltung — und die Grenze zur E-Akte

Fall 1: Raumbuchung in einer Stadtverwaltung

Eine Stadtverwaltung mit rund 1.000 Rufnummern — die Größenordnung, in der eine Verwaltung noch überschaubar und schon unübersichtlich ist. Gesucht war die Buchung von 60 Besprechungsräumen über mehrere Gebäude, inklusive Ausstattung und Bestuhlung.

Ergebnis: SharePoint-Liste. Drei Listen, genauer gesagt: Räume, Ausstattung, Buchungen. Keine Zeile enthält personenbezogene Daten über den Namen des Buchenden hinaus. Niemand muss vor einer Buchung geschützt werden. Das Mengengerüst liegt bei einigen Tausend Datensätzen im Jahr und wird über eine Aufbewahrungsregel begrenzt. Lizenzkosten: null. Betrieb: das Organisationsamt, mit einer benannten Vertretung.

Der einzige Punkt, der Aufwand gekostet hat, war die Barrierefreiheit. Eine Power App ist ein internes Portal, und interne Portale unterliegen denselben Anforderungen wie andere Angebote der Verwaltung.

Was das konkret bedeutet — Tastaturbedienbarkeit, Kontraste, Beschriftungen von Formularfeldern — steht in Barrierefreiheit in Microsoft 365: BITV-Pflichten für interne Portale und Vorlagen. Planen Sie diesen Aufwand ein, bevor die App fertig ist. Danach ist es Nacharbeit.

Fall 2: Fundbüro

Fundsachen sind ein wunderbares Beispiel dafür, wie eine harmlose Anwendung Anforderungen bekommt. Am Anfang: eine Liste mit Fundort, Gegenstand, Datum. Nach einem halben Jahr: Fotos der Fundsachen, Kontaktdaten der Finder, Auszahlungen von Finderlohn, Verwertungsvermerke, und die Frage, ob das Bürgerbüro die Kontaktdaten der Finder sehen darf.

Diese Anwendung steht auf der Kippe. Die saubere Antwort in der Praxis war: SharePoint-Liste bleibt, aber die Kontaktdaten wandern in eine zweite, eng berechtigte Liste in einer eigenen Website — nicht in eindeutige Berechtigungen pro Element. Zwei Behälter mit klaren Rechten sind stabiler als ein Behälter mit tausend Ausnahmen. Erst wenn die Trennung nicht mehr gelingt, weil die Zugriffsregel wirklich am einzelnen Datensatz hängt, beginnt der Fall für Dataverse.

Fall 3: Antragsformulare im Sozialbereich

Eine Stadtverwaltung mit SharePoint im Sozialbereich hatte den klassischen Fall: Ein Formular zur Erfassung von Anträgen, gebaut vom Fachamt, gewachsen über zwei Jahre, mittlerweile mit rund 40.000 Datensätzen und einer Berechtigungsstruktur, die aus 6.000 einzeln berechtigten Elementen bestand. Die Anwendung funktionierte. Sie war nur nicht mehr erklärbar — weder gegenüber dem Datenschutzbeauftragten noch gegenüber der eigenen IT.

Hier war Dataverse die richtige Antwort, und zwar nicht wegen der 40.000 Zeilen, sondern wegen der Zugriffsregel. Geschäftseinheiten je Sachgebiet, Sicherheitsrollen mit den Zugriffsebenen „nur eigene“, „Geschäftseinheit“ und „tief“, dazu Spaltensicherheit für zwei Felder. Die Migration hat gedauert, die Lizenzen haben Geld gekostet, und beides war unstrittig, weil die Alternative eine nicht auditierbare Fachanwendung mit Sozialdaten gewesen wäre.

TIPP · Der Satz, der die Diskussion im Fachamt beendet „Wir bauen das auf SharePoint, solange wir jeder Person im Amt alle Datensätze zeigen dürfen. Sobald das nicht mehr gilt, wird es ein Projekt mit Lizenzkosten.“ Dieser Satz verlagert die Diskussion vom Werkzeug zur Fachlichkeit — und dorthin gehört sie. Das Fachamt kann beurteilen, wer was sehen darf. Es kann nicht beurteilen, ob eine Nachschlagespalte delegierbar ist. Und es muss das auch nicht.

 

Und wo die Grenze zur E-Akte liegt

Der wichtigste Satz dieses Beitrags für alle, die mit Registratur und Schriftgutverwaltung zu tun haben: Eine Power App auf einer Liste oder auf Dataverse ist keine E-Akte. Sie darf es auch nicht werden — nicht, weil die Technik es verbietet, sondern weil das Landes-E-Government-Recht und Ihr Aktenplan bestimmen, wo aktenrelevantes Schriftgut geführt wird und wie es nachvollziehbar bleibt.

Skizze 5: Arbeitsebene, Übergabepunkt, Aktenebene. Der Übergabepunkt muss beim Entwurf definiert werden, nicht bei der ersten Akteneinsicht.

Praktisch heißt das: Die Fachanwendung erfasst, prüft, steuert und erzeugt gegebenenfalls ein Dokument. Sobald daraus ein Vorgang mit Aktenrelevanz wird — Bescheid, Beschlussvorlage, Vertrag, Nachweis gegenüber Dritten — geht das Ergebnis in das führende System für Schriftgut, mit Aktenzeichen, Metadaten und Aufbewahrungsbezeichnung. Die App bleibt Zulieferer.

Wo genau diese Grenze verläuft und was SharePoint in diesem Zusammenhang leisten kann und was nicht, ist Thema von SharePoint als E-Akte? Was geht, was nicht und wo die Grenze nach Landesrecht liegt. Die Systematik vom Aktenplan zur Aufbewahrungsbezeichnung steht in Schriftgutverwaltung mit Microsoft 365: Vom Aktenplan zur Aufbewahrungsbezeichnung, und wie Fristen, Disposition und Vernichtungsnachweis technisch umgesetzt werden, in Aufbewahrung und Aussonderung mit Purview: Fristen, Disposition, Vernichtungsnachweis. Für Dataverse gilt: Aufbewahrung ist dort ein eigenes Thema mit eigenen Werkzeugen und nicht identisch mit den Aufbewahrungsrichtlinien, die Sie für SharePoint kennen.

WARNUNG · Die Anwendung, die zur Akte wurde Das häufigste Muster in der Praxis: Eine Fachanwendung wächst über Jahre, bis sie faktisch der einzige Ort ist, an dem der Vorgang vollständig nachvollziehbar ist. Kein Aktenplan, keine Fristen, keine Aussonderung, kein Vernichtungsnachweis. Auffallen wird das bei der ersten Akteneinsicht, der ersten Beschwerde oder der ersten Prüfung durch das Rechnungsprüfungsamt. Der Aufwand, das im Nachhinein zu ordnen, übersteigt den Aufwand, die Grenze am ersten Tag zu ziehen, um ein Vielfaches. Das ist eine Erfahrung, keine Drohung.

 

Der organisatorische Teil, den die Technik nicht löst

Zwei Dinge gehören in jede Einführung von Power Platform in einer Verwaltung, und beide sind nicht technisch.

Erstens: eine Regel, wer bauen darf. Nicht als Verbot, sondern als Angebot. „Sie dürfen im Environment Persönliche Produktivität alles ausprobieren. Wenn Sie eine Anwendung für Ihr Amt bauen wollen, melden Sie sich — dann bekommen Sie einen Platz in DEV, eine Vorlage und jemanden, der gegenliest.“ Das kostet weniger Zeit als das nachträgliche Einsammeln gewachsener Anwendungen.

Zweitens: die Beteiligung des Personalrats an der richtigen Stelle. Eine Raumbuchung ist unkritisch. Eine Anwendung, die erfasst, wer welchen Vorgang wann bearbeitet hat, kann zur Verhaltens- und Leistungskontrolle geeignet sein — und genau das ist der Punkt, an dem eine Dienstvereinbarung Klarheit schafft, statt sie zu verhindern. Die Auditierung in Dataverse, die Sie für die Rechnungsprüfung einschalten, ist technisch dieselbe Funktion, die dieses Thema auslöst.

Bausteine für eine solche Vereinbarung — Zweckbindung, Auswertungsverbot, Rollen, Kontrollrechte — sind in Copilot und Personalrat: Bausteine einer Dienstvereinbarung zusammengestellt und lassen sich auf Fachanwendungen übertragen.

Wenn Sie diesen Rahmen nicht nebenbei aufbauen möchten: Genau diese Fragen — Environment-Zuschnitt, Berechtigungsmodell, Lizenzfolgen, Abgrenzung zum Fachverfahren — sind der Kern der Microsoft-365-Beratung für Verwaltungen. Und für die Menschen, die die Anwendungen später bauen und betreuen, lohnt ein Blick auf die Microsoft-365-Schulung für Verwaltungen — weil der Unterschied zwischen einer wartbaren und einer nicht wartbaren Power App fast immer im Wissen der erbauenden Person liegt, nicht im Werkzeug.

FAKTENCHECK · Delos Cloud, nüchtern betrachtet Für Verwaltungen, die auf eine souveräne Betriebsvariante warten, ist Delos Cloud ein Thema. Für die Frage SharePoint-Liste oder Dataverse ändert sich dadurch am Entscheidungsmuster nichts: Die Berechtigungsanforderung entscheidet, nicht die Betriebsplattform. Was sich ändern kann, ist der Funktionsumfang und der Zeitpunkt der Verfügbarkeit einzelner Dienste. Beides sollten Sie nicht unterstellen, sondern zum Zeitpunkt Ihrer Planung erfragen und schriftlich festhalten. Wer eine Fachanwendung heute auf Dataverse baut, sollte die Portabilität der Datenhaltung als eigene Anforderung formulieren — unabhängig davon, welche Plattform am Ende darunter liegt.

 

Der Sachstand zum Angebot selbst ist in Delos Cloud für Kommunen: Was das Angebot ist, wen es betrifft und was fehlt beschrieben.

Häufige Fragen

Können wir eine Anwendung später von SharePoint nach Dataverse umziehen?

Ja, und der Weg ist vorgesehen: Power Apps bietet eine Funktion, mit der eine SharePoint-Liste in eine Dataverse-Tabelle überführt und dazu optional eine App erzeugt wird. Rechnen Sie trotzdem mit Nacharbeit. Die Datenstruktur zieht mit, das Berechtigungsmodell nicht — und genau dafür haben Sie den Umzug ja gemacht. Sicherheitsrollen, Geschäftseinheiten und Teams müssen neu entworfen werden. Planen Sie den Umzug als kleines Projekt mit Abnahme durch das Fachamt, nicht als Wartungsfenster.

Reicht es nicht, in der App bestimmte Felder auszublenden?

Nein. Was die Oberfläche verbirgt, bleibt in der Datenquelle sichtbar. Wer die Liste direkt öffnet, exportiert oder über einen Flow abfragt, sieht alles. Sichtbarkeitssteuerung in der App ist Bedienkomfort, keine Zugriffsbeschränkung. In einer Datenschutzprüfung ist dieser Unterschied erfahrungsgemäß die erste Frage.

Wie viele Datensätze verträgt eine SharePoint-Liste in der Praxis?

Technisch bis 30 Millionen Elemente. Praktisch beginnt die Sorgfalt bei 5.000, weil Filter und Sortierungen über nicht indizierte Spalten dann gegen die Listenansichtsschwelle laufen. Mit indizierten Spalten und delegierbaren Formeln arbeiten Anwendungen auch bei einigen Zehntausend Datensätzen zuverlässig. Der Engpass ist fast nie die Menge, sondern die Formel, die nicht delegiert wird.

Brauchen wir für Dataverse eigene Administratoren?

Sie brauchen mindestens zwei Personen, die Sicherheitsrollen, Geschäftseinheiten und Lösungen verstehen — und diese Personen müssen erreichbar sein, wenn die Anwendung im Betrieb ist. Ob das eigene Beschäftigte sind, das kommunale Rechenzentrum oder ein Systemhaus, ist eine Frage der Organisation und nicht der Qualität. Wichtig ist nur, dass die Rolle benannt, vertreten und in einer Leistungsbeschreibung beschrieben ist.

Wie sich Rollen und Schnittstellen zwischen Verwaltung und Rechenzentrum sinnvoll abgrenzen lassen, behandelt Microsoft 365 und das kommunale Rechenzentrum: Rollen, Schnittstellen, Zweitmeinung.

Was passiert mit unseren Power Apps, wenn die erbauende Person das Amt verlässt?

Ohne Vorsorge: Die App läuft weiter, bis etwas kaputtgeht, und dann findet sich niemand, der sie ändern darf. Das Power Platform Admin Center weist auf Apps ohne gültigen Eigentümer hin — nutzen Sie diese Liste. Zusätzlich gehört in jede Fachanwendung ab einer bestimmten Bedeutung ein zweiter Miteigentümer sowie die Ablage der Lösung im Versionsstand. Bei Anwendungen im Default-Environment ist genau das der Grund, warum sie dort nicht hingehören.

Ist eine Power App auf einer SharePoint-Liste datenschutzrechtlich unproblematisch?

Diese Frage lässt sich pauschal nicht beantworten, und ich beantworte sie hier auch nicht rechtlich. Fachlich gilt: Die Verarbeitung personenbezogener Daten braucht eine Rechtsgrundlage, eine Zweckbindung, ein Löschkonzept und einen Eintrag im Verzeichnis der Verarbeitungstätigkeiten — unabhängig davon, ob die Daten in einer Liste oder in Dataverse liegen. Die Wahl der Technik entscheidet nicht über die Zulässigkeit, sondern darüber, ob Sie die Zugriffsbeschränkung, die Sie zugesagt haben, technisch auch einhalten können. Für kirchliche Träger gilt dasselbe Muster unter DSG-EKD beziehungsweise KDG.

Die Besonderheiten dort sind in Microsoft 365 in Kirche, Diakonie und Caritas: DSG-EKD, KDG und Mitarbeitervertretung zusammengefasst.

Sollen wir Fachanwendungen überhaupt selbst bauen oder ein Fachverfahren beschaffen?

Die Grenze verläuft dort, wo ein Fachverfahren mit Rechtsbezug, Schnittstellen zu Landesverfahren oder Zertifizierungsanforderungen gefordert ist. Melderegister, Kassenverfahren, Bauaufsicht — das sind keine Power-Apps-Themen. Raumbuchung, Fundbüro, interne Anträge, Materialbestellung, Terminlisten der Vergabestelle: dort ist Power Platform häufig schneller, günstiger und näher an der eigenen Organisation als jedes zugekaufte Produkt. Die schwierige Zone liegt dazwischen, und dort hilft die Vorfrage aus dem ersten Abschnitt.

Wie sichern wir Power Apps und Dataverse eigentlich?

Für Dataverse gibt es Systemsicherungen, und Sandbox-Environments lassen sich kopieren und zurücksetzen. Für das Default-Environment gibt es keine manuelle Sicherung. Für SharePoint-Listen gilt das übliche Microsoft-365-Modell mit Papierkorb und Aufbewahrung — was nicht dasselbe ist wie eine Wiederherstellung in einen definierten Zustand. Welche Risikoentscheidung Sie hier treffen, sollten Sie dokumentieren, weil sie spätestens im Prüfbericht auftaucht.

Die Abwägung ist in Backup und Wiederherstellung in Microsoft 365: Die Risikoentscheidung fürs Rechnungsprüfungsamt ausgearbeitet.

Wir haben Schutzbedarf „hoch“ festgestellt. Ändert das die Antwort?

Es verschiebt die Schwelle deutlich in Richtung Dataverse und in Richtung eigenes Environment mit engen Regeln. Bei hohem Schutzbedarf werden Nachvollziehbarkeit, Zugriffsbeschränkung und Trennung von Entwicklung und Betrieb zu Anforderungen, nicht zu Empfehlungen. Ob und wie sich das mit den Bausteinen des IT-Grundschutzes zusammenbringen lässt, ist eine eigene Betrachtung.

Den Abgleich für die Praxis finden Sie in Schutzbedarf und Microsoft 365: IT-Grundschutz-Abgleich für die Praxis. Ergänzend regelt der Zugriffsweg selbst einen Teil des Risikos — dazu Conditional Access für Verwaltungen: Regelwerk für Rathaus, Bauhof und Homeoffice.

Fazit

Die Frage „SharePoint-Liste oder Dataverse“ ist keine Frage der Datenmenge und keine Frage des Anspruchs. Sie ist eine Frage der Berechtigung. Solange jede Person im zuständigen Amt jeden Datensatz sehen darf, ist die SharePoint-Liste die überlegene Wahl: schneller gebaut, ohne Zusatzlizenzen, von den Fachämtern betreibbar. Sobald ein Datensatz für Teile der Belegschaft unsichtbar sein muss, sobald Relationen über zwei Ebenen hinausgehen oder eine belastbare Änderungshistorie gebraucht wird, ist Dataverse nicht der luxuriösere, sondern der einzige tragfähige Weg — mit allem, was daran hängt.

Was Sie unabhängig von dieser Entscheidung tun sollten, sind drei Dinge. Erstens: dem Default-Environment einen ehrlichen Namen geben, die Freigabegrenzen setzen, mindestens zwei Systemadministratoren benennen und eine restriktive Richtlinie zur Datenverlustvermeidung darüberlegen. Zweitens: drei Environments für Fachanwendungen aufsetzen und in einer Environment-Gruppe führen, damit die Regeln einmal gesetzt werden und dann gelten. Drittens: die Grenze zur Schriftgutverwaltung schriftlich ziehen, bevor die erste Anwendung sie überschreitet.

Und die unangenehme Wahrheit zum Schluss: Die Lizenzfolgen sind der Teil, der in Beschlussvorlagen am häufigsten fehlt. Wer eine Fachanwendung auf Dataverse vorschlägt, ohne die Premium-Lizenzen für alle Nutzer auszuweisen, legt der Kämmerei eine Rechnung in die Schublade, die dort ein halbes Jahr später gefunden wird. Rechnen Sie das vorher aus. Es ist die billigste halbe Stunde des gesamten Projekts.

WEITER IN DIESER SERIE › Microsoft 365 in der Kommune: Was Sie wirklich entscheiden müssen (und was nicht) › Microsoft-365-Einführung in der Verwaltung: Konzeptionsphase in 4,5 Tagen und die Beschlussvorlage › Dokumenten-KI in der Verwaltung: Posteingang, Anträge und Klassifizierung › Wenn die Aufbewahrungsrichtlinie einfach aufhört: SharePoint-Störungsanalyse in der Verwaltung › Notfallübung für die Verwaltungs-IT: SharePoint verschlüsselt, Admin-Konto übernommen, Bürgertelefon tot › ADFS oder Entra ID in der Verwaltung: Die Entscheidung entlang der Fachverfahren