Dein Großkunde hat ein Lieferantenportal eingeführt. Ab sofort soll alles dort rein: Rechnungen, Lieferscheine, Statusinformationen. Klingt nach Fortschritt. Ist in der Praxis meistens das Gegenteil: jemand lädt PDFs manuell hoch, während die eigentliche Buchführung noch im eigenen System läuft. Zweimal tippen, zweimal prüfen, doppelte Fehlerchance.
Das eigentliche Problem ist nicht das Portal des Kunden. Das eigentliche Problem ist, dass du kein eigenes hast.
Was fehlt, wenn das Portal fehlt
Lieferanten-Portale großer Einkäufer entstehen nicht, weil die Einkäufer boshaft sind. Sie entstehen, weil der Einkäufer keine strukturierten Daten von seinen Lieferanten bekommt. PDFs per Mail, Rechnungen im Briefumschlag, Statusanfragen per Telefon — das ist aus Sicht eines Einkaufscontrollers mit 200 Lieferanten nicht handhabbar.
Das Gegenmittel wäre ein eigenes Portal, über das deine Kunden oder Lieferanten Daten strukturiert austauschen — Auftragsstatus abrufen, Rechnungen einreichen, Lieferscheine hochladen, Reklamationen erfassen. Wer so etwas anbietet, hat das bessere Argument gegen das Fremdsystem.
Das Problem: Wer einmal ein eigenes Datenmodell in einem separaten System aufgebaut hat und dann feststellt, dass es mit dem internen SQL-Server-Backend nicht synchron läuft, hat doppelte Arbeit und doppelte Fehlerquellen. Die Stammdaten existieren zweimal. Adressen, Konditionen, Bestellnummern — alles zweimal pflegbar, also zweimal falsch.
Ein Kundenportal ohne eigene Datenverdoppelung ist technisch möglich. Es erfordert aber die richtige Schnittstelle zum bestehenden Backend.
Was Power Pages ist — und was nicht
Power Pages ist ein Werkzeug aus der Microsoft Power Platform. Es erzeugt öffentliche Webseiten mit Authentifizierung, direkt verbunden mit Dataverse oder, über einen Custom Connector, mit einem SQL-Server-Backend.
Ein externer Nutzer — Lieferant, Kunde, Bewerber — bekommt einen Link, meldet sich an und sieht genau das, was er sehen soll. Nichts mehr. Die Datenhaltung bleibt im bestehenden System, nicht in einem zweiten.
Was Power Pages nicht ist: ein vollständiges CMS, ein Shop-System oder ein Ersatz für eine professionell entwickelte Webanwendung. Es ist ein schnell aufzusetzendes Portal für strukturierte Interaktionen mit externen Nutzern. Die Stärke liegt in der Integration mit Microsoft 365, Entra ID (früher Azure AD) und Power Automate, nicht in der visuellen Designfreiheit.
In meiner Praxis ist Power Pages die sauberste Antwort auf eine spezifische Anforderung: extern, authentifiziert, datenbankgebunden — und ohne eine zweite Datenhaltung einzuführen.
Wie der Aufbau ohne Datenverdoppelung funktioniert
Der kritische Punkt ist die Datenhaltungsschicht. Power Pages kann auf zwei Arten an Daten kommen:
Variante 1 — über Dataverse. Dataverse ist Microsofts eigene Cloud-Datenbank. Einfach anzubinden, gut dokumentiert, Audit-Trail inklusive. Nachteil: Die Daten liegen in Dataverse, nicht im eigenen SQL Server. Wer Bestelldaten, Kundennummern und Konditionen aus dem ERP oder aus Access in Dataverse replizieren möchte, baut unweigerlich eine Synchronisation — und damit genau das, was die Frage im Titel vermeiden will.
Variante 2 — über Custom Connector direkt zum SQL Server. Power Pages kann über Power Automate und Custom Connectors Lese- und Schreibzugriffe direkt gegen einen SQL Server abwickeln. Das ist technisch aufwendiger als Dataverse, aber die sauberere Architektur: eine Datenhaltung, ein Wahrheitsanker, kein Abgleich.
Aus Sicht der Datenarchitektur ist Variante 2 die richtige Wahl, wenn ein SQL-Server-Backend bereits vorhanden ist und als System of Record gelten soll. Dataverse ist keine schlechte Technologie — sie ist nur die falsche Schicht, wenn das Ziel „keine doppelten Stammdaten“ lautet.
Was im Portal konkret abgebildet werden kann
Typische Anwendungsfälle, die ich im norddeutschen Mittelstand sehe:
Lieferanten-Self-Service. Lieferschein-Upload, Rechnungserfassung mit Prüfung gegen Bestellnummer, Status-Tracking. Der Lieferant sieht nur seine eigenen Vorgänge, nicht die der anderen.
Kundenportal für Auftragsstatus. Kunde gibt Bestellnummer ein, bekommt aktuellen Status aus dem SQL-Server-Backend. Kein Telefonat, kein Sachbearbeiter als Zwischenschicht.
Bewerber-Tracking. Bewerbungen strukturiert erfassen, automatisch eingangsbestätigen, Status kommunizieren. Leuchtet für jeden ein, der weiß wie viel Aufwand unstrukturierter Bewerbungseingang kostet.
In allen drei Fällen bleibt das Datenmodell im SQL Server. Das Portal ist das Fenster, nicht das Lager.
Wo die Grenzen liegen
Power Pages ist kein Rundum-Sorglos-Portal. Ehrliche Einschränkungen:
Die Lizenzkosten sind nicht trivial. Power Pages rechnet pro authentifiziertem externem Nutzer pro Monat oder pro Login-Session. Bei wenigen Nutzern rechnet sich das schnell; bei hundert externen Lieferanten mit monatlichem Zugriff muss man nachrechnen.
Die Designfreiheit ist begrenzt. Power Pages bringt Templates und einen Low-Code-Designer mit. Wer ein durchgängig gebrandetes Portal mit komplexen Interaktionen erwartet, wird Kompromisse machen oder Custom-Code in das Portal einbauen müssen.
Die Custom-Connector-Anbindung an SQL Server ist kein Einzeiler. Sie ist machbar, braucht aber jemanden, der die Power Platform kennt und das SQL-Server-Schema versteht. Wer hier den billigsten Weg geht, landet entweder bei Dataverse-Synchronisation — also Datenverdoppelung — oder bei einem fragilen Connector, der beim nächsten Schema-Update bricht.
Und: Wer bisher keine Microsoft-365-Infrastruktur hat, baut eine Abhängigkeit auf, bevor das erste Formular läuft. Das ist kein Argument gegen Power Pages, aber ein Faktor, den man kennen sollte.
Was das für Dich bedeutet
Wenn du ein eigenes Portal anbieten willst — gegenüber Kunden, Lieferanten oder Bewerbern — ist Power Pages ein realistischer Weg, das zu tun, ohne eine zweite Datenhaltung einzuführen. Die Grundbedingung: Das SQL-Server-Backend ist sauber strukturiert, Tabellen und Sichten sind dokumentiert, und der Zugriff ist über Stored Procedures oder Views so gekapselt, dass ein externer Connector nicht unkontrolliert ins Schema schreibt.
Das ist keine Power-Pages-Anforderung. Das ist eine Anforderung an die Datenarchitektur, die ohnehin erfüllt sein sollte.
Ein Kundenportal ist kein Digitalisierungsprojekt. Es ist ein Fenster in ein System, das schon existiert. Wenn das System ordentlich gebaut ist, ist das Fenster eine Woche Arbeit. Wenn nicht, hilft kein Portal.
Wer sich das einmal in Ruhe anschauen möchte, erreicht mich über sesoft.de/kostenloses-erstgestraech-sichern.
Quellen
- Microsoft Power Pages Dokumentation: learn.microsoft.com/power-pages
- Power Platform Lizenzübersicht (Microsoft): aka.ms/PowerPlatformLicensing
- Übersichtsartikel: Access mit SQL Server durch Power Platform ergänzen — sesoft.de
Über den Autor
Sönke Schäfer berät seit über 25 Jahren KMU in Norddeutschland bei der pragmatischen Erweiterung von Microsoft-Access- und SQL-Server-Anwendungen. Sein Schwerpunkt liegt auf Datenarchitektur für Bestandssysteme — Datenflüsse sauber halten, externe Anbindungen ohne Datenverdoppelung aufbauen, Portale und Automatisierungen auf vorhandenen Strukturen aufsetzen. Büro in Sierksdorf, Ostholstein. Erreichbar für Unternehmen in Lübeck, Kiel, Hamburg und im gesamten norddeutschen Raum, auf Wunsch auch remote.
