Viele Microsoft 365-Lösungen zur Datenerfassung und Prozessautomatisierung starten mit dem bekannten Muster: eine SharePoint-Liste für die Datenhaltung, Power Apps als Oberfläche, Power Automate für Genehmigungen. Für einen Pilot funktioniert das – für einen Urlaubsprozess mit Konten, HR-Genehmigung und Stammdaten stößt das Modell aber schnell an Grenzen: Berechtigungen werden undurchsichtig, Daten lassen sich nicht sauber normalisieren und in Beziehung setzen, und kritische Logik landet in Flows, die niemand mehr vollständig überblickt.

In einem aktuellen Projekt habe ich die Komponenten streng an den Best Practices der professionellen Anwendungsentwicklung ausgerichtet und bewusst eine dreischichtige Lösungsarchitektur gewählt: Anwendungsoberfläche in SharePoint, strukturierte Datenhaltung in Dataverse, rechenintensive und transaktionale Logik in Azure Functions. Der Beitrag fokussiert weniger auf Implementierungsdetails als auf Nutzen, IT-Strategie und Entscheidungskriterien – damit du einschätzen kannst, ob dieser Weg für eure HR- oder Fachanwendung passt.

Was gehört in einer HR-Lösung und wurde bereits umgesetzt?

eine Mitarbeiterverwaltung als Startpunkt für Stammdaten mit Lookup auf das Microsoft 365 Benutzerkonto
ein Berechtigungs- und Rollensystem auf Basis von Entra-ID-Sicherheitsgruppen
ein Urlaubskonto je Mitarbeiter mit vertraglichem Urlaubsanspruch und Urlaubssaldo
ein Urlaubsantrag mit Werktagsberechnung im Formular und Genehmigungsstatus
eine Buchungslogik mit Urlaubsposten (Reserviert, Genehmigt, Verbraucht, Storniert) als Basis für Saldoberechnungen
ein HR-Hub als Einstiegspunkt für HR und Führungskräfte.

Mitarbeiterverwaltung als SharePoint-Webpart mit Stammdaten und Urlaubsansprüchen — HR-Lösung mit Urlaubsverwaltung: Stammdaten und Urlaubsansprüche zentral pflegbar – eingebettet in das Intranet, das HR und Mitarbeitende bereits nutzen. Der Screenshot zeigt eine beispielhafte Anordnung der Webparts.

Urlaubsantrag als SharePoint-Webpart mit HR-Hub und Genehmigeransicht — Urlaubsantrag und HR-Genehmigung in einer Oberfläche – ohne Wechsel in eine separate Power App. Stammdaten, bestehende Anträge und Salden werden kontextabhängig geladen.

Kurz-Antwort

Für Fachanwendungen mit Konten, Genehmigungen und Stammdaten – etwa im Personalwesen – ist die Kombination aus SharePoint Framework (SPFx), Dataverse und Azure Functions oft nachhaltiger als reine SharePoint-Listen mit Power Apps und Power Automate. SPFx bringt die Anwendung direkt ins Intranet – ohne zusätzliche Power-Apps-Lizenzen für Nutzer, die nur beantragen oder genehmigen. Dataverse liefert ein relationales Datenmodell mit durchgängiger Sicherheit. Azure Functions übernehmen Berechnungen und Transaktionen außerhalb des Browsers. Power Automate bleibt sinnvoll für Benachrichtigungen – die Kernlogik gehört in versionierbaren, IT-betriebenen Code.

Ausgangslage: Wann reicht Low-Code – und wann nicht?

SharePoint-Listen mit Power Apps und Power Automate bleiben die richtige Wahl für erste Piloten, einfache Workflows und dokumentenlastige Szenarien. Sobald aus einem Prozess eine Fachanwendung wird – mit definierten Anforderungen an Datenmodell, Berechtigungen, Benutzerrollen und zentraler Verarbeitungslogik lohnt sich der Blick auf eine professionellere Architektur.

Mein Anwendungsbeispiel liegt im Personalwesen: strukturierte Erfassung und Verarbeitung von Mitarbeiterstammdaten und Urlaubsanträgen. Die Daten unterliegen hohen Anforderungen an Zugriff, Verfügbarkeit und Integrität – einschließlich der DSGVO. Damit war klar: Kein schneller Prototyp, der später beim Datenmodell und bei der Prozesslogik Kompromisse erzwingt.

Der Schritt zur Fachanwendung zeigte sich an den Anforderungen an Berechtigungen und Nachvollziehbarkeit: Urlaubsansprüche, Urlaubskonten, HR-Genehmigung über Abteilungsgrenzen hinweg, auditierbare Buchungslogik und langfristiger Betrieb durch die IT.

Für dieses Projekt waren SharePoint-Listen mit Power Apps und Power Automate nicht die passende Basis: Der nötige Entwicklungsaufwand passt nicht zu klassischen Low-Code-Werkzeugen, und die Lösung lässt sich nur eingeschränkt mit moderner, KI-gestützter Softwareentwicklung in Git pflegen und weiterentwickeln.

Die Zielarchitektur sollte deshalb auf Komponenten basieren, die SPFx, Dataverse und Azure Functions in einem durchgängigen Entwicklungsprozess verbinden – nicht nur für den ersten Release, sondern für den laufenden Betrieb.

Praxis-Tipp: Eine HR-Urlaubsanwendung auf Microsoft 365 sollte von SharePoint-Listen auf Dataverse umsteigen, sobald Konten, Genehmigungsketten und feingranulare Rollen fachlich erforderlich sind – nicht erst, wenn die Listen technisch „voll“ sind.

Lösungsarchitektur in drei Schichten

Die Zielarchitektur setzt mit SPFx und Azure Functions auf eine professionelle Codebasis und trennt bewusst Präsentation, Daten und Prozesse – eine Entscheidung auf IT-Strategie-Ebene, nicht nur auf Tool-Ebene:

Schicht	Tool	Nutzen für Organisation und Fachbereich
Präsentation	SharePoint Framework (SPFx)	HR-Prozesse dort, wo Mitarbeitende ohnehin arbeiten – einheitliche Anwendungsoberfläche, kein Medienbruch
Daten	Dataverse	Stammdaten, Anträge und Buchungen in einem Modell mit klaren Beziehungen und Governance
Prozesse	Azure Functions	Zuverlässige Saldo-Berechnung und Transaktionen – unabhängig von Einzelpersonen und Flow-Besitzern

Der Nutzer bleibt in SharePoint. HR und IT gewinnen ein wartbares Gesamtsystem statt einer Ansammlung aus Listen, Apps und undokumentierten Flows.

Kurz-Check

Architekturprinzip: Drei Schichten – Präsentationsschicht (SPFx-Client), Daten (Dataverse), Prozesse (Azure Functions) – trennen Oberfläche, Datenmodell und Rechenlogik bewusst.
Nutzerort: Mitarbeitende und HR arbeiten in vertrauten SharePoint-Seiten; die Fachanwendung läuft im Hintergrund strukturiert in Dataverse.
IT-Verantwortung: Die IT betreibt Datenmodell und Kernlogik zentral; Fachbereiche profitieren von stabileren Prozessen statt Flow-Wildwuchs.

Welchen Nutzen haben Fachbereiche und IT durch die Lösungsarchitektur?

Klassische Low-Code-Projekte bieten keinen integrierten Entwicklungsansatz für mehrschichtige Architekturen. Power Apps und Flows existieren nebeneinander und müssen bei veränderten Anforderungen oder Änderungen im Datenmodell immer wieder neu aufeinander abgestimmt werden. Für eine unternehmensweite HR-Anwendung mit mehreren Modulen und klarer Rollentrennung müssen Bedienoberflächen und Prozesslogik jedoch zwingend gemeinsam entwickelt werden. Diese Vorteile lassen sich realisieren:

Benutzerorientierung: Die Benutzeroberfläche bietet nur die Funktionen, die in der Logik- und Datenhaltungsschicht entsprechend der Rolle vorgesehen sind.
SharePoint-Integration: Bestehende Intranetseiten oder HR-Teamsites können genutzt werden, da Berechtigungssteuerung und Datenhaltung in der Datenhaltungsschicht gekapselt sind.
Transparenz & Geschwindigkeit: Hintergrundprozesse werden synchron zur Laufzeit ausgeführt; Anwender sehen direkt das Ergebnis, statt später benachrichtigt zu werden.
Lebenszyklus: Im laufenden Betrieb können Neuanforderungen und Bugfixes sauber vom produktiven Code getrennt, entwickelt und deployed werden.
Releasefähigkeit: Änderungen führen immer zu Abhängigkeiten zwischen den Schichten der Lösungsarchitektur. Im Notfall können alle Komponenten auf einen betriebsfähigen Stand zurückgesetzt werden.

Daten und Compliance: Warum Dataverse statt SharePoint-Listen?

Strategischer Nutzen eines relationalen Datenmodells

Listen eignen sich für Dokumente, einfache Aufgaben und Kollaboration. Sobald Antrag, Buchung und Saldo logisch zusammenhängen, wird das Listenmodell zur Risikoquelle:

Auswertungen über Abteilungen, Jahre und Urlaubsarten werden aufwendig und fehleranfällig.
Mehrstufige Beziehungen (Antrag → Details → Buchungen → Saldo) erfordern Workarounds statt klarem Modell.
Geschäftsvorgänge (Antrag speichern, buchen, Status setzen) lassen sich in Flows nur schwer zuverlässig und auditierbar abbilden.

In Dataverse hängen Anträge, Buchungen, Salden und Stammdaten fachlich sauber zusammen. HR und Controlling können sich auf nachvollziehbare Daten verlassen; die IT behält das Modell unter zentraler Governance.

Übersicht des Dataverse-Datenmodells für HR mit Anträgen, Buchungen und Salden — Datenmodell auf einen Blick: Anträge, Buchungen und Salden relational verknüpft – Grundlage für Reporting, Prüfung und Erweiterung.

Urlaubsbuchungen nach Ledger-Prinzip für nachvollziehbare Salden — Buchungen als nachvollziehbare Historie: Salden bleiben prüfbar – wichtig für HR, Revision und spätere Anpassungen am Regelwerk.

Praxis-Tipp: Dataverse eignet sich für HR-Fachanwendungen, weil Anträge, Buchungen und Salden in einem relationalen Modell mit durchgängiger Sicherheit geführt werden – SharePoint-Listen bleiben für Dokumente und einfache Listenprozesse die bessere Wahl.

Berechtigungen: Governance statt Vererbungs-Chaos

Fachanwendungen brauchen klare Berechtigungsstrukturen, die zentral eingerichtet und durchgesetzt werden. In der Zielarchitektur ordnen Entra-ID-Sicherheitsgruppen Benutzerrollen den SPFx-Webparts zu; Dataverse-Sicherheitsrollen leiten Tabellenzugriffe aus denselben Gruppen ab.

Bei Datenhaltung in SharePoint-Listen greifen dagegen klassische SharePoint-Gruppen mit Berechtigungsstufen auf Seitenebene – durch kollaborative Funktionen nur schwer zentral steuerbar.

Typische Folgen in SharePoint-Listen-Projekten:

Risiko	Geschäftliche Auswirkung
Vererbung	Zu viele Personen sehen oder bearbeiten HR-Daten
Einzelberechtigungen	Nicht mehr auditierbar, hoher Pflegeaufwand
Workarounds	Separate Listen, Filter, versteckte Flow-Logik
Trennung fehlt	„Liste bearbeiten“ ≠ „darf genehmigen“

Prozesse und Betrieb: Azure Functions statt Power Automate-Wildwuchs

Power Automate bleibt wertvoll für Benachrichtigungen, Eskalationen und Integrationen (z. B. Teams, E-Mail). Für Kern-Geschäftslogik – Urlaubssaldo aus Buchungshistorie, Jahresurlaub buchen ohne Doppelbuchungen – ist zentraler Betrieb über Azure Functions strategisch überlegen:

Keine Abhängigkeit von Einzelkonten: Flows laufen im Kontext von Benutzerkonten und brechen oft, wenn der Ersteller die Organisation verlässt („Orphaned Flows“).
Weniger Berechtigungsrisiken: Für Flows erhalten Benutzerkonten häufig zusätzliche Rechte oder Admin-Zugriffe – mit Risiken für unkontrollierte Verarbeitung von Anwendungsdaten.
IT-Betrieb: Workflow- und Logikschicht laufen als Azure-Ressource – entwickelt mit denselben Tools wie die Präsentationsschicht, versioniert im zentralen GitHub-Repository.

Praxis-Tipp: Power Automate eignet sich für HR-Benachrichtigungen und leichte Workflows; rechenintensive Kernlogik und Transaktionen gehören in IT-betriebene Azure Functions, die unabhängig von Mitarbeiterkonten laufen.

Entscheidungshilfe: Klassischer Weg vs. dreischichtige Fachanwendung

Kriterium	Listen + Power Apps + Power Automate	SPFx + Dataverse + Azure Functions
Time-to-Market	Anfangs schnell, dann abnehmend	Nach sauberem Setup dauerhaft planbar
Entwicklungstools	Low-Code, Citizen Development	KI-gestützt: Cursor, VS Code, SPFx-Toolkit
Weiterentwicklung	Getrennte Dev-/Prod-Umgebungen	Git, GitHub, Branching auf Feature-Ebene
Test & Support	Manuell, wenig Debugging	Automatisierte Funktionstests möglich
Anwendungsoberfläche	Oft spürbarer Systembruch	Gewohnte SharePoint-Umgebung
Datenmodell	Flach, Grenzen bei Relationen	Relational, Ledger-Prinzip, erweiterbar
Berechtigungen	Kollaborativ: folgt SharePoint-Struktur	Zentral: Sicherheitsgruppen, Dataverse-Rollen
Kritische Berechnungen	Flows, schwer testbar	Azure Functions: serverseitig, versionierbar
Governance & Lifecycle	Flows und Apps im Benutzerkontext	Git, Releases, App-Katalog
Lizenzen (Nutzer)	Oft Power Apps Premium pro aktivem Nutzer	SharePoint + Dataverse-Kapazität (je nach Tenant)

Die Wahl ist keine Religion. Für Urlaub mit Konten, HR-Genehmigung und Stammdatenverwaltung war die dreischichtige Variante auf Dauer die klar wartbarere und governance-fähigere Architektur.

Kurz-Check

Pilot vs. Betrieb: Low-Code (Listen, Power Apps, Power Automate) ist im Prototyping konkurrenzfähig; SPFx + Dataverse + Azure gewinnen bei langfristigem Betrieb und Governance.
Lizenzen: Bei vielen reinen Nutzern ohne App-Baukasten-Nutzung vermeidet SPFx oft zusätzliche Power-Apps-Lizenzen.
Entscheidungsregel: Sobald HR-Prozesse Konten, Genehmigungsketten und feingranulare Rollen brauchen, lohnt sich der Schritt von Listen zu Dataverse und von Flow-Kernlogik zu Azure.

Governance: Git und moderne Entwicklung als strategischer Hebel

Versionskontrolle, KI-gestützte Entwicklung und klare Release-Prozesse haben das Verhältnis verschoben: Gegenüber reinem Low-Code kann die IT Fachanwendungen heute mit hoher Iterationsgeschwindigkeit liefern – ohne an Qualität und Governance zu sparen.

GitHub als Rückgrat der IT-Governance

Nachvollziehbarkeit: Wer hat wann welche Funktion oder Oberfläche geändert?
Qualitätssicherung: Pull Requests und Reviews vor Produktion.
Umgebungen: Test und Produktion bleiben über Releases synchron dokumentierbar.
Team-Besitz: Die Lösung gehört dem Repository – nicht „der Flow-Version von Sandra“.

GitHub-Repository als zentrale Quelle für HR-Lösung und Releases — Zentrale Quelle der Wahrheit: Änderungen an Oberfläche und Prozesslogik sind versioniert und für IT und Audit nachvollziehbar.

Praxis-Tipp: HR-Fachanwendungen auf Microsoft 365 sollten von Anfang an in Git versioniert werden – nur so lassen sich stabiler Betrieb und funktionale wie technische Weiterentwicklung Hand in Hand organisieren.

KI-gestützte Entwicklung (z. B. mit Cursor) beschleunigt die Umsetzung und verzahnt Präsentationsschicht, Prozesslogik und Datenhaltung. Was dennoch nicht zu kurz kommen darf: Fachbereich und IT definieren Anforderungen und treffen die Architekturentscheidung – Bedienbarkeit, Funktionen, Rollen, Datenmodell. Der Mensch setzt die Strategie; die Werkzeuge liefern Tempo bei der Umsetzung.

Fazit: Wann lohnt sich dieser Architekturansatz?

Die Kombination SPFx + Dataverse + Azure Functions lohnt sich strategisch, wenn:

die Lösung langfristig betrieben wird und mehr als ein einfacher Workflow ist,
Rollen, Konten und Datenbeziehungen fachlich und rechtlich sauber sein müssen,
die Oberfläche im SharePoint-Intranet leben soll,
IT-Governance, Tests und Releases professionellen Maßstäben genügen müssen.

SharePoint-Listen mit Power Apps und Power Automate bleiben richtig für schnelle Experimente und einfache Prozesse. Sobald aus dem Urlaubsantrag eine HR-Fachanwendung wird, ist der dreischichtige Ansatz oft der nachhaltigere Weg.

Du planst eine HR- oder Fachanwendung auf Microsoft 365 und möchtest Architektur, Datenmodell und Umsetzung gemeinsam durchdenken? Kontakt aufnehmen – von der strategischen Skizze bis zur ausgerollten Lösung im App-Katalog.