Inhaltsverzeichnis
Das Wichtigste vorab
Muss eine Power-Apps-Anwendung im GxP-Umfeld validiert werden?
Eine Power-Apps-Anwendung muss entsprechend ihrem vorgesehenen GxP-Einsatz bewertet und abgesichert werden. Low-Code ist keine Ausnahme von den Anforderungen an ein zuverlässig arbeitendes computergestütztes System. Betrachten Sie App, Datenquelle, Formeln, Konnektoren und Berechtigungen gemeinsam. Der Nachweis betrifft die konfigurierte Anwendung und ihren Prozess, nicht pauschal die gesamte Microsoft-Plattform.
Einordnung und Geltungsbereich
Canvas- und modellgesteuerte Apps sowie unterschiedliche Datenquellen besitzen verschiedene Kontrollmöglichkeiten. Die folgenden Prüffragen gelten als Ausgangspunkt; konkrete Produktfunktionen werden nicht für jede Variante vorausgesetzt.
Die App-Oberfläche ist nur ein Teil des Systems
Formeln und Verbindungen können fachliche Entscheidungen verändern. Prüfen Sie Pflichtfelder, Grenzwerte, Statuswechsel und die Behandlung unvollständiger Rückgaben. Eine leere Ergebnisliste kann bedeuten, dass keine Daten existieren, aber auch, dass der Zugriff fehlgeschlagen oder begrenzt ist. Diese Zustände dürfen im Prozess nicht unbemerkt gleichbehandelt werden.
Microsoft beschreibt Application Lifecycle Management für Power Platform. Für Ihren GxP-Prozess müssen Entwicklung, Prüfung und Bereitstellung nachvollziehbar zusammenpassen. Dokumentieren Sie den geprüften App-Stand einschließlich Umgebungsvariablen und relevanter Verbindungen. Ein Versionsname allein belegt nicht, welche Datenquelle produktiv angesprochen wird.
Den vorgesehenen Einsatz der konkreten App beschreiben
Bewerten Sie die Anwendung, nicht das Etikett Low-Code. Eine App zur Raumreservierung hat einen anderen Einfluss als eine Anwendung, die Prüfwerte erfasst oder einen Materialstatus verändert. Beschreiben Sie Daten, Entscheidungen und mögliche Folgen einer falschen Verarbeitung. Daraus ergibt sich der angemessene Prüf- und Kontrollumfang.
Erfassen Sie App-Typ, Umgebung, Datenquellen, Konnektoren, eingebundene Flows und tatsächlich verwendete Identitäten. Die Oberfläche ist nur ein Teil des Systems. Ein Nutzer kann eine Aktion anstoßen, die über eine andere Verbindung im Hintergrund ausgeführt wird. Benennen Sie deshalb, wo Berechtigungen und fachliche Regeln tatsächlich durchgesetzt werden.
Microsoft beschreibt ALM für Power Platform als Lebenszyklus einschließlich Anforderungen, Entwicklung, Test, Änderung, Bereitstellung und Betrieb. Solutions und weitere Werkzeuge können diese Arbeit unterstützen. Sie sind jedoch kein allgemeiner GxP-Nachweis. Welche Komponenten und Einstellungen tatsächlich übertragen werden, muss für Ihr gewähltes Modell festgestellt werden.
Anforderungen aus Daten und Entscheidungen ableiten
Formulieren Sie Anforderungen so, dass ihre Wirkung geprüft werden kann. „Die App ist sicher“ bleibt zu allgemein. „Ein Produktionsbenutzer kann ein Prüfergebnis erfassen, aber den freigegebenen Grenzwert nicht verändern“ beschreibt eine konkrete Grenze. Ergänzen Sie den Umgang mit fehlenden Eingaben, wiederholten Aktionen und einer nicht erreichbaren Datenquelle.
Unterscheiden Sie Eingabeprüfung im Bildschirm von Regeln in der Datenverarbeitung. Wenn ein Datensatz auch über eine andere App, einen Import oder einen Flow geändert werden kann, deckt die Bildschirmprüfung nicht alle Wege ab. Die Architektur sollte erkennbar machen, welche Kontrolle für welchen Weg gilt. Ungeklärte Alternativwege bleiben im Risikobild sichtbar.
| Anforderungsbereich | Konkrete Frage | Eigene Prüfmethode |
|---|---|---|
| Identität | Unter welcher Identität wird gelesen und geschrieben? | Rollen und Verbindungen mit tatsächlichen Aktionen prüfen |
| Eingabe | Welche Werte und Zustände sind zulässig? | Normal-, Grenz- und Fehlerfälle verwenden |
| Verarbeitung | Welche Regeln verändern den Datensatz? | Ergebnis unabhängig mit der Fachregel vergleichen |
| Ausnahme | Was geschieht bei Timeout oder fehlender Quelle? | Kontrollierte Unterbrechung und Wiederanlauf |
| Nachvollziehbarkeit | Welcher App-Stand erzeugte die Aufzeichnung? | Version, Datenbezug und erforderliche Historie rekonstruieren |
Beispiel: doppelte Erfassung durch wiederholtes Speichern
Das Szenario ist konstruiert. Eine App erfasst einen Prüfwert zu Probe P-55. Wegen langsamer Rückmeldung klickt ein Benutzer zweimal auf Speichern. Die eigene Anforderung verlangt genau eine nachvollziehbare Aufzeichnung beziehungsweise einen klar erkannten Wiederholungsversuch. Der Artikel unterstellt keine automatische Standardlösung jeder Power-App.
Bereiten Sie die Probe und den erwarteten Wert vor. Führen Sie einen normalen Speichervorgang aus und vergleichen Sie Datenquelle und Anzeige. Wiederholen Sie anschließend die Aktion unter kontrollierter Verzögerung. Prüfen Sie den tatsächlichen Datenbestand, nicht nur die Bestätigungsmeldung. Zwei identische Anzeigen können im Hintergrund zwei unterschiedliche Datensätze repräsentieren.
Ergänzen Sie eine Unterbrechung nach dem Schreiben, aber vor der Rückmeldung, soweit sich dies in einer geeigneten Testumgebung nachbilden lässt. Das Team muss wissen, wie ein unklarer Ausgang erkannt und geklärt wird. Ein blindes erneutes Speichern kann eine Dopplung verursachen. Die geeignete Kontrolle kann etwa eine geprüfte Geschäftskennung und einen geregelten Wiederanlauf verwenden.
| Testfall | Aktion | Erwartete fachliche Aussage |
|---|---|---|
| Normaler Eingang | P-55 mit gültigem Wert speichern | Richtiger Wert genau dem vorgesehenen Vorgang zugeordnet |
| Fehlende Pflichtangabe | Ohne notwendige Kennung speichern | Keine unklare freigaberelevante Aufzeichnung |
| Wiederholung | Speichern kontrolliert mehrfach auslösen | Gewählte Wiederholungsregel wirkt |
| Verbindungsfehler | Datenquelle vorübergehend unterbrechen | Fehler ist sichtbar, Datenstand wird geklärt |
| Unberechtigte Änderung | Kritischen Parameter mit Fachbenutzer ändern | Zugriff entspricht der festgelegten Grenze |
Umgebungen, Verbindungen und Bereitstellung kontrollieren
Trennen Sie Entwicklung und vorgesehene produktive Nutzung angemessen. Eine Test-App kann andere Datenquellen oder Berechtigungen verwenden. Dokumentieren Sie diese Unterschiede und prüfen Sie deren Auswirkungen. Ein bestandener Test mit einem Entwicklerkonto belegt nicht die richtige Funktion mit den späteren Fachbenutzern.
Bei Bereitstellung ist zu bestätigen, dass die richtige App-Version, zugehörige Flows und notwendige Konfiguration im Ziel vorhanden sind. Verbindungen und Umgebungswerte verdienen besondere Aufmerksamkeit, wenn sie auf andere Quellen oder Identitäten verweisen. Eine erfolgreich importierte Solution bestätigt noch nicht den fachlichen End-to-End-Ablauf.
Erhalten Sie einen nachvollziehbaren Standnachweis. Dazu gehören die tatsächlich benötigten Komponenten und deren Beziehungen. Eine Änderung an einem gemeinsamen Flow kann mehrere Apps beeinflussen. Die Auswirkungsbewertung muss deshalb über die einzelne Oberfläche hinausreichen. Nicht jede Plattformänderung erfordert denselben Testumfang; der betroffene Einsatz bestimmt die Auswahl.
Betrieb, Eigentümerschaft und Fehlerklärung vorbereiten
Benennen Sie fachlichen und technischen Verantwortlichen sowie Vertretung. Prüfen Sie, was bei einem Rollenwechsel oder Ausscheiden des ursprünglichen Entwicklers geschieht. Persönlich gebundene Verbindungen und unklare Eigentümerschaft können den Betrieb erschweren. Die Übergabe sollte deshalb Zugänge, Konfiguration und erforderliches Wissen berücksichtigen.
Definieren Sie den Umgang mit fehlerhaften Aufzeichnungen. Wer erkennt einen unvollständigen Speichervorgang, wer bewertet die fachliche Wirkung und wie wird korrigiert? Eine technische Reparatur darf den ursprünglichen Zustand nicht unbemerkt verdecken. Benötigte Nachvollziehbarkeit und Aufbewahrung folgen dem konkreten Datenprozess.
Für den nächsten Release empfiehlt sich ein kleiner gepflegter Satz kritischer Regressionstests. Er sollte wichtige Eingaben, Rechte, Verarbeitungsregeln und Fehlerwege abdecken. Ein reiner Klicktest der Oberfläche ist schwächer als ein Vergleich des tatsächlich entstandenen Datensatzes und seiner Verwendung. Die Auswahl wird bei Änderungen erneut bewertet.
Arbeitsvorlage: App, Flow und Datenquelle als einen Ablauf prüfen
Wählen Sie einen vollständigen Vorgang und zeichnen Sie seine Verarbeitung in wenigen Zeilen nach. Im Beispiel erfasst eine Fachrolle einen Prüfwert, ein Flow ergänzt einen Status und eine Datenquelle speichert den Datensatz. Benennen Sie für jeden Übergang Identität, relevante Regel und erwarteten Zustand. Die Prüfung einer Oberfläche allein reicht für diese Kette nicht.
Dokumentieren Sie auch den unklaren Ausgang. Nach einem Timeout kann der Datensatz bereits geschrieben sein. Ein erneuter Klick ist dann eine fachlich relevante Wiederholung. Die Sollregel beschreibt, wie der richtige Zielzustand festgestellt und ein doppelter Vorgang vermieden oder erkannt wird. Prüfen Sie dies mit kontrollierten bekannten Daten.
Verwenden Sie die Ablaufakte bei Änderungen. Eine neue Datenquelle oder andere Verbindung kann den bisherigen Rechte- und Fehlernachweis verändern. Der gleiche App-Name bedeutet keine identische Architektur. Bewerten Sie den tatsächlich bereitgestellten Gesamtstand und erhalten Sie den Bezug zu den Referenzfällen.
| Ablauffeld | Konstruierter Eintrag | Nachweis |
|---|---|---|
| Eingang | Probe P-55 mit gültigem Prüfwert. | Richtige Kennung und Einheit. |
| Benutzer | Fachrolle ohne Stammdatenänderungsrecht. | Erlaubte und unerlaubte Aktion geprüft. |
| Flow | Bezeichnete Verarbeitung unter eigener Verbindung. | Technische Identität und Wirkung bekannt. |
| Speicherung | Ein eindeutiger Geschäftsfall im Ziel. | Keine ungeklärte doppelte Aufzeichnung. |
| Fehler | Verbindung wird nach möglichem Schreiben unterbrochen. | Wiederanlauf klärt den tatsächlichen Bestand. |
| Bereitstellung | App, Flow und relevante Zielkonfiguration. | Geprüfter Stand ist tatsächlich aktiv. |
Die nächsten Schritte
- Vorgesehenen Einsatz und kritische Entscheidungen beschreiben.
- App, Datenhaltung, Verbindungen und Rollen abgrenzen.
- Normal-, Grenz- und Fehlerfälle über die gesamte Kette prüfen.
- Versionierte Freigabe und kontrollierte Änderungen organisieren.
Häufige Fragen zu Microsoft Power Apps
Macht Dataverse die App automatisch GxP-konform?
Kann der Fachbereich die App selbst entwickeln?
Muss jede optische Änderung erneut validiert werden?
Ist Low-Code automatisch weniger validierungsaufwendig?
Nicht automatisch. Der Umfang richtet sich nach vorgesehenem Einsatz, Risiken und Komplexität. Eine einfache Oberfläche kann mehrere Datenquellen und Flows verbinden. Geeignete Plattformnachweise können unterstützen, ersetzen aber die Bewertung der eigenen Konfiguration und Prozesse nicht. Entscheidend ist, welche fachlichen Entscheidungen und Aufzeichnungen die konkrete App beeinflusst.
Können wir eine App nach Änderungen einfach erneut veröffentlichen?
Für einen GxP-relevanten Einsatz benötigen Änderungen eine passende Auswirkungsbewertung, geeignete Prüfungen und eine nachvollziehbare Nutzungsentscheidung. Berücksichtigen Sie verbundene Flows, Datenquellen und Rechte. Prüfen Sie den tatsächlich bereitgestellten Zielstand. Eine technische Veröffentlichung bestätigt nicht allein, dass die geänderte Anwendung für den vorgesehenen Prozess geeignet bleibt.
Wie behandeln wir eine persönlich gebundene Verbindung nach Personalwechsel?
Prüfen Sie Eigentümerschaft, Authentifizierung und betroffene Verarbeitung. Planen Sie den Wechsel kontrolliert und bestätigen Sie den fachlichen Ablauf. Ein neuer Besitzername allein beweist keine richtige Datenverbindung. Benennen Sie Vertretung und Störungsweg, damit Betrieb und benötigte Nachweise nicht von einer einzelnen Person abhängen.
Ist ein bestandener App-Test nach einer Flowänderung weiterhin gültig?
Nur soweit seine Aussage noch übertragbar ist. Eine geänderte Verarbeitung kann Daten, Status, Rechte oder Wiederholung beeinflussen. Bewerten Sie diese Abhängigkeit und führen Sie passende End-to-End-Fälle erneut aus. Eine unveränderte Oberfläche bestätigt nicht automatisch unveränderte fachliche Wirkung.
Quellen & fachlicher Stand
Die Quellen bilden den fachlichen Rahmen. Tabellen, Checklisten und ausdrücklich illustrative Beispiele sind eigene methodische Ableitungen, keine wörtlichen Normvorgaben. Herstellerinformationen sind auf die eingesetzte Version und Konfiguration zu beziehen.
- Europäische Kommission: EU-GMP Annex 11, Computerised Systems (2011)
- Microsoft: Application lifecycle management with Power Platform
Zuletzt fachlich geprüft am 14.10.2026.
Daniel Herrmann Consulting
Damit Ihr Team den nächsten Schritt sicher planen kann.
Wir unterstützen Sie dabei, die Ausgangslage einzuordnen, Verantwortlichkeiten zu klären und passende Nachweise im Betrieb umzusetzen. Welche Unterstützung sinnvoll ist, hängt von Ihrem System, Ihrem Team und dem konkreten Ziel ab.
- IT-GxP-Audit →
Offene Punkte und Prioritäten für Ihren Betrieb einordnen.
- IT-GxP-Consulting →
Vereinbarte Systemprojekte strukturiert umsetzen und übergeben.