{"id":45802,"date":"2026-10-23T09:00:49","date_gmt":"2026-10-23T07:00:49","guid":{"rendered":"https:\/\/2b-advice.com\/?p=45802"},"modified":"2026-10-22T16:07:36","modified_gmt":"2026-10-22T14:07:36","slug":"webhook-fehler-governance-workflows","status":"publish","type":"post","link":"https:\/\/2b-advice.com\/fr\/2026\/10\/23\/webhook-fehler-governance-workflows\/","title":{"rendered":"Webhook-Fehler in Governance-Workflows richtig behandeln"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Webhook-Fehler in Governance-Workflows: Freigaben nachvollziehbar verarbeiten<\/h1>\n\n

Governance-Workflows k\u00f6nnen Freigaben in Microsoft Teams einbinden und die Entscheidung anschlie\u00dfend an das f\u00fchrende System \u00fcbertragen. F\u00fcr die Nachvollziehbarkeit ist jedoch nicht allein ma\u00dfgeblich, ob eine R\u00fcckmeldung technisch ankommt. Das System muss auch pr\u00fcfen, auf welchen Vorgang und welche Fassung sie sich bezieht, ob die entscheidende Person berechtigt ist und welche Wirkung die R\u00fcckmeldung noch haben darf.<\/p>\n\n

Besondere Anforderungen entstehen, wenn Nachrichten mehrfach, versp\u00e4tet oder gar nicht eintreffen. Dann m\u00fcssen technischer Empfang, fachliche Pr\u00fcfung und wirksame Zustands\u00e4nderung unterscheidbar bleiben. Eine erfolgreiche \u00dcbertragung belegt f\u00fcr sich genommen keine g\u00fcltige Freigabe.<\/p>\n\n

Versions\u00e4nderungen w\u00e4hrend einer offenen Freigabe<\/h2>\n\n

Ein Beispiel verdeutlicht die organisatorische Bedeutung: F\u00fcr eine Verarbeitung wird eine Freigabe zur Version V3 angefordert. Die zust\u00e4ndige Person erh\u00e4lt dazu eine Aufgabe in Teams. W\u00e4hrend diese noch offen ist, erg\u00e4nzt der Fachbereich einen weiteren Datenempf\u00e4nger. Damit liegt inzwischen Version V4 vor.<\/p>\n\n

Anschlie\u00dfend trifft die Best\u00e4tigung aus der urspr\u00fcnglichen Teams-Aufgabe ein. Wegen einer wiederholten \u00dcbertragung wird sie zweimal zugestellt. Zu kl\u00e4ren ist nun, ob die Entscheidung bereits verarbeitet wurde und ob sie f\u00fcr den aktuellen Stand noch verwendet werden darf.<\/p>\n\n

W\u00fcrde die Integration lediglich den Status auf \u201efreigegeben\u201c setzen, k\u00f6nnte eine Entscheidung zu V3 auf die ge\u00e4nderte Fassung V4 \u00fcbertragen werden. Der Prozess muss deshalb den Bezug zur gepr\u00fcften Fassung erhalten und eine ungepr\u00fcfte \u00dcbernahme verhindern.<\/p>\n\n

Der Beitrag zu Governance-Workflows in Microsoft 365<\/a> erl\u00e4utert den Zusammenhang zwischen dem Arbeitskanal und der f\u00fchrenden Governance-Akte. F\u00fcr den Betrieb ist erg\u00e4nzend zu regeln, wie dieser Zusammenhang bei Zustell- und Verarbeitungsfehlern erhalten bleibt.<\/p>\n\n

Technische Zustellung und fachliche Freigabe unterscheiden<\/h2>\n\n

Microsoft Graph unterscheidet zwischen der Zustellung einer \u00c4nderungsbenachrichtigung und ihrer anschlie\u00dfenden Verarbeitung. Eine rechtzeitig empfangene erfolgreiche HTTP-Antwort best\u00e4tigt dort die Zustellung. F\u00fcr eine sp\u00e4tere Verarbeitung empfiehlt Microsoft unter anderem, Benachrichtigungen zun\u00e4chst dauerhaft in einer Warteschlange abzulegen und ihren Empfang zu best\u00e4tigen.<\/p>\n\n

Damit ist noch nicht festgestellt, ob eine fachliche Entscheidung zul\u00e4ssig ist oder bereits gespeichert wurde. Zudem beschreibt Microsoft begrenzte Wiederholungen und Situationen, in denen Benachrichtigungen verloren gehen k\u00f6nnen.<\/p>\n\n

F\u00fcr einen Freigabeprozess sollten daher mindestens Versand, Eingang, fachliches Pr\u00fcfergebnis und ausgef\u00fchrte Zustands\u00e4nderung getrennt nachvollziehbar sein. Eine R\u00fcckmeldung kann technisch angenommen und fachlich zur\u00fcckgewiesen werden, etwa weil sie eine veraltete Fassung betrifft.<\/p>\n\n

Dabei ist die konkrete Schnittstelle zu ber\u00fccksichtigen. Eine Microsoft-Graph-\u00c4nderungsbenachrichtigung ist nicht automatisch der R\u00fcckkanal einer Teams-Freigabe. Aktionen auf Teams-Karten k\u00f6nnen beispielsweise Daten zur serverseitigen Verarbeitung an eine Anwendung \u00fcbergeben. Welche Identit\u00e4tspr\u00fcfung, Transportantwort und Fehlerbehandlung erforderlich sind, h\u00e4ngt von der gew\u00e4hlten Umsetzung ab. Aussagen \u00fcber Graph-Benachrichtigungen lassen sich deshalb nicht ohne Pr\u00fcfung auf jeden Teams-Prozess \u00fcbertragen.<\/p>\n\n

Ereignisse eindeutig zuordnen und doppelte Ausf\u00fchrung verhindern<\/h2>\n\n

Eine Ereignis-ID dient dazu, eine R\u00fcckmeldung bei erneuter Zustellung wiederzuerkennen. Die Kennung sollte f\u00fcr dasselbe Ereignis stabil bleiben. Die CloudEvents-Spezifikation beschreibt hierf\u00fcr die Kombination aus Ereignisquelle und ID.<\/p>\n\n

F\u00fcr den Freigabeprozess sind drei Bez\u00fcge auseinanderzuhalten: die betroffene Verarbeitung, der konkrete Freigabeauftrag und die einzelne R\u00fcckmeldung. Die Objekt-ID der Verarbeitung allein gen\u00fcgt nicht, da derselbe Vorgang mehrere Pr\u00fcfungen und Entscheidungen durchlaufen kann.<\/p>\n\n

Eine eindeutige Kennung erleichtert die Zuordnung. Sie belegt jedoch weder die Berechtigung des Absenders noch die fachliche G\u00fcltigkeit der Entscheidung.<\/p>\n\n

Die Verarbeitung sollte zudem idempotent sein. Das bedeutet hier, dass eine erneute Verarbeitung derselben Entscheidung keine zus\u00e4tzliche fachliche Wirkung erzeugt. Eine bereits ausgewertete R\u00fcckmeldung darf weder den Freigabeschritt noch nachgelagerte Aufgaben erneut ausl\u00f6sen. Microsoft beschreibt dieses Muster f\u00fcr wiederholt zugestellte Nachrichten.<\/p>\n\n

Zu ber\u00fccksichtigen sind auch gleichzeitige Zustellungen. Eine Pr\u00fcfung, ob die Kennung bereits vorhanden ist, mit anschlie\u00dfendem getrenntem Speichern kann unzureichend sein. Der Schutz vor doppelter Ausf\u00fchrung und die Speicherung des Ergebnisses m\u00fcssen technisch aufeinander abgestimmt werden. Werden Aktionen in weiteren Systemen ausgel\u00f6st, sind daf\u00fcr zus\u00e4tzliche Abgleichmechanismen erforderlich.<\/p>\n\n

Dar\u00fcber hinaus ist der Zustand des Freigabeauftrags zu pr\u00fcfen. Ein zweiter Klick kann eine neue Nachrichten-ID erzeugen, obwohl derselbe Auftrag bereits abgeschlossen ist. Die Ereigniskennung ersetzt daher keine fachliche Zustandspr\u00fcfung.<\/p>\n\n

Freigaben an die gepr\u00fcfte Fassung binden<\/h2>\n\n

Im Beispiel bezieht sich die Best\u00e4tigung auf V3, w\u00e4hrend bei ihrem Eingang bereits V4 vorliegt. Die R\u00fcckmeldung sollte als Entscheidung zur urspr\u00fcnglichen Fassung dokumentiert werden. Eine automatische Freigabe der neuen Fassung l\u00e4sst sich daraus nicht ableiten.<\/p>\n\n

Die zust\u00e4ndige Freigaberolle ben\u00f6tigt einen Hinweis auf die zwischenzeitliche \u00c4nderung. Sie kann dann bewerten, welche Bedeutung der zus\u00e4tzliche Datenempf\u00e4nger f\u00fcr die Entscheidung hat, und \u00fcber V4 entscheiden. Die fr\u00fchere R\u00fcckmeldung bleibt mit ihrem urspr\u00fcnglichen Versionsbezug erhalten.<\/p>\n\n

OWASP beschreibt f\u00fcr Transaktionsautorisierungen den Schutz entscheidungsrelevanter Daten vor Ver\u00e4nderungen und eine serverseitige Pr\u00fcfung unmittelbar vor der Ausf\u00fchrung. F\u00fcr den hier betrachteten Prozess ist entsprechend sicherzustellen, dass sich die gepr\u00fcfte Fassung nicht zwischen Versionspr\u00fcfung und Speicherung der Freigabe unbemerkt \u00e4ndert.<\/p>\n\n

Eine m\u00f6gliche technische Absicherung sind bedingte \u00c4nderungen. Sie werden nur ausgef\u00fchrt, wenn der erwartete Stand noch vorliegt. HTTP unterst\u00fctzt daf\u00fcr beispielsweise If-Match. Voraussetzung ist, dass die konkrete Anwendung das Verfahren korrekt umsetzt.<\/p>\n\n

Der Versionsbezug muss au\u00dferdem die entscheidungsrelevanten Unterlagen erfassen. Die Version einer Verarbeitung belegt nicht automatisch, welche Fassung eines verlinkten Vertrags oder welcher Stand einer Anbieterbewertung gepr\u00fcft wurde. Dokumentversionen und Beziehungen sind deshalb im Zusammenhang mit der Entscheidung festzuhalten. Der Beitrag zu Versionierung und Audit-Trail<\/a> behandelt diesen fachlichen Kontext.<\/p>\n\n

Identit\u00e4t und aktuelle Berechtigung pr\u00fcfen<\/h2>\n\n

Eine erfolgreiche Anmeldung \u00fcber Microsoft 365 beantwortet noch nicht, ob die Person den konkreten Vorgang im betreffenden Mandanten freigeben darf. Ma\u00dfgeblich sind die aktuellen Rechte f\u00fcr die jeweilige Aktion.<\/p>\n\n

OWASP empfiehlt Berechtigungspr\u00fcfungen bei jedem Zugriff sowie eine standardm\u00e4\u00dfige Ablehnung, wenn keine Erlaubnis vorliegt. Eine mit der Nachricht \u00fcbermittelte Rollenbezeichnung oder die Sichtbarkeit einer Teams-Aufgabe reicht als Berechtigungsnachweis nicht aus.<\/p>\n\n

Ebenso sind Single Sign-on und Provisioning zu unterscheiden. Die Anlage und Deaktivierung von Benutzerkonten sowie \u00c4nderungen an Rollen ben\u00f6tigen entsprechende Prozesse. Microsoft behandelt diese Aufgaben gesondert im Rahmen der Anwendungsbereitstellung. SSO allein belegt nicht, dass zwischenzeitlich entzogene Rechte bereits in allen beteiligten Systemen ber\u00fccksichtigt wurden.<\/p>\n\n

Vor der wirksamen Entscheidung sollte das f\u00fchrende System daher Identit\u00e4t, aktuelle Berechtigung, Mandant, Freigabeauftrag und Version pr\u00fcfen. Die Zuordnung muss auf vertrauensw\u00fcrdig ermittelten Informationen beruhen.<\/p>\n\n

Wiederholungen und Abgleich nach Fehlerart regeln<\/h2>\n\n

Eine vor\u00fcbergehende Verbindungsst\u00f6rung kann einen erneuten \u00dcbertragungsversuch rechtfertigen. Eine fehlende Berechtigung oder eine veraltete Entscheidungsgrundlage wird durch wiederholtes Senden dagegen nicht behoben.<\/p>\n\n

Beim Retry-Muster ist au\u00dferdem zu ber\u00fccksichtigen, dass eine Aktion bereits erfolgreich ausgef\u00fchrt worden sein kann, obwohl ihre Antwort verloren ging. Microsoft weist auf dieses Risiko hin. Eine ungepr\u00fcfte Wiederholung k\u00f6nnte dann zus\u00e4tzliche Wirkungen ausl\u00f6sen.<\/p>\n\n

Vor einem erneuten Versuch ist deshalb der gespeicherte Bearbeitungsstand abzugleichen. Wurde die R\u00fcckmeldung bereits ausgewertet, ist dieses Ergebnis zu ber\u00fccksichtigen. Bleibt die Verarbeitung unklar, ben\u00f6tigt der Fall einen geregelten Kl\u00e4rungsweg. Aus der blo\u00dfen Existenz einer Teams-Nachricht darf keine Freigabe abgeleitet werden, wenn ein belastbarer Entscheidungsnachweis fehlt.<\/p>\n\n

Zus\u00e4tzlich ist ein regelm\u00e4\u00dfiger Abgleich offener Freigabeauftr\u00e4ge mit den eingegangenen und verarbeiteten R\u00fcckmeldungen erforderlich. F\u00fcr unterst\u00fctzte Graph-Ressourcen beschreibt Microsoft Lebenszyklusbenachrichtigungen und eine erneute Datensynchronisation nach Zustelll\u00fccken. Die M\u00f6glichkeiten unterscheiden sich jedoch nach Ressourcentyp. Eine allgemeine Wiederherstellungsgarantie f\u00fcr beliebige Teams-Prozesse ergibt sich daraus nicht.<\/p>\n\n

Fehlerf\u00e4lle und Zust\u00e4ndigkeiten festlegen<\/h2>\n\n

Die folgende Matrix ist eine organisatorische und technische Arbeitshilfe f\u00fcr den beschriebenen Freigabeprozess. Sie stellt kein gesetzlich vorgeschriebenes Ablaufschema dar. S\u00e4mtliche F\u00e4lle sind Beispiele.<\/p>\n\n

\n\n\n\n\n\n\n\n\n\n\n
Fehlerfall<\/th>\nErforderliche Pr\u00fcfung<\/th>\nZust\u00e4ndigkeit und Bearbeitung<\/th>\nNachweis<\/th>\n<\/tr>\n<\/thead>\n\n
Doppelte R\u00fcckmeldung<\/td>\nEreigniskennung, Freigabeauftrag, Inhalt und gespeichertes Ergebnis abgleichen<\/td>\nIntegrationsbetrieb: identische Wiederholung ohne erneute Zustands\u00e4nderung behandeln; widerspr\u00fcchliche Inhalte unter derselben Kennung kl\u00e4ren<\/td>\nEing\u00e4nge, erkannte Wiederholung und unver\u00e4nderter fachlicher Stand<\/td>\n<\/tr>\n\n
Versp\u00e4tete Best\u00e4tigung<\/td>\nBest\u00e4tigte V3 mit aktueller V4 und dem erg\u00e4nzten Empf\u00e4nger vergleichen<\/td>\nFachliche Freigaberolle: Best\u00e4tigung nicht automatisch \u00fcbernehmen; \u00c4nderung pr\u00fcfen und \u00fcber die aktuelle Fassung entscheiden<\/td>\nVersionsvergleich, Grund der Zur\u00fcckweisung und neuer Pr\u00fcfauftrag<\/td>\n<\/tr>\n\n
Fehlende R\u00fcckmeldung<\/td>\nOffenen Auftrag, Versand, Eingang und verf\u00fcgbaren Verarbeitungsnachweis abgleichen<\/td>\nIntegrationsbetrieb und Prozessverantwortung: sichere Wiederholung oder erneute Best\u00e4tigung veranlassen; keine automatische Freigabe<\/td>\nAbgleichprotokoll und weiterer Bearbeitungsweg<\/td>\n<\/tr>\n\n
Unberechtigte Aktion<\/td>\nVertrauensw\u00fcrdig ermittelte Identit\u00e4t, aktuelle Rechte, Mandant und Aktion pr\u00fcfen<\/td>\nIAM\/Security und Prozessverantwortung: Aktion ablehnen, Zust\u00e4ndigkeit kl\u00e4ren und bei Verdacht eine Sicherheitspr\u00fcfung einleiten<\/td>\nErgebnis der Berechtigungspr\u00fcfung und unver\u00e4nderter Vorgang<\/td>\n<\/tr>\n\n
Nicht zuordenbare R\u00fcckmeldung<\/td>\nFehlende oder widerspr\u00fcchliche Referenzen auf Verarbeitung und Auftrag pr\u00fcfen<\/td>\nIntegrationssupport: R\u00fcckmeldung zur Kl\u00e4rung zur\u00fcckhalten; keine Zuordnung anhand \u00e4hnlicher Titel vornehmen<\/td>\nFehlercode, zul\u00e4ssig gespeicherte Referenzen und Kl\u00e4rungsergebnis<\/td>\n<\/tr>\n\n<\/tbody>\n<\/table>\n<\/div>\n\n

F\u00fcr offene Fehlerf\u00e4lle sind Verantwortliche und risikogerechte Bearbeitungsfristen festzulegen. Ebenso muss geregelt sein, welche Transportantwort bei einer fachlich ung\u00fcltigen R\u00fcckmeldung erfolgt. Andernfalls kann die Integration dieselbe unbrauchbare Nachricht wiederholt zustellen, obwohl der Fehler eine fachliche Kl\u00e4rung erfordert.<\/p>\n\n

Umgang mit \u00c4nderungen vorab bestimmen<\/h2>\n\n

Nicht jede \u00c4nderung muss dieselbe Folge f\u00fcr eine offene Freigabe haben. Eine rein redaktionelle Korrektur kann anders zu bewerten sein als ein zus\u00e4tzlicher Datenempf\u00e4nger. Voraussetzung ist eine vorab dokumentierte Regelung dazu, welche \u00c4nderungen entscheidungsrelevant sind und wann eine fr\u00fchere Bewertung weiterverwendet werden darf.<\/p>\n\n

Eine solche Ausnahme sollte nicht erst w\u00e4hrend einer St\u00f6rung festgelegt werden. Auch die technische Reparatur durch den Support ist von der fachlichen Entscheidung zu trennen. Supportrechte allein sollten keine Berechtigung begr\u00fcnden, Freigaben nachzutragen.<\/p>\n\n

Je nach H\u00e4ufigkeit und Sensibilit\u00e4t der Entscheidungen kann es zudem angemessener sein, Teams nur f\u00fcr die Benachrichtigung und einen sicheren Einstieg in den f\u00fchrenden Vorgang zu nutzen. Die Entscheidung betrifft Bedienkomfort, Integrationsaufwand und die Beherrschbarkeit der Fehlerf\u00e4lle.<\/p>\n\n

Nachweise f\u00fcr Support und Revision<\/h2>\n\n

Der Support ben\u00f6tigt eine zusammenh\u00e4ngende Sicht vom Freigabeauftrag bis zum Verarbeitungsergebnis. Dazu geh\u00f6ren Ereignis- und Auftragskennung, Quelle, Mandant, Eingangszeitpunkt, Versionsbezug, Pr\u00fcfergebnis, Wiederholungen und offene Kl\u00e4rungsschritte.<\/p>\n\n

Der Zeitpunkt der Benutzeraktion sollte vom technischen Empfang und von der Speicherung unterscheidbar bleiben. OWASP empfiehlt f\u00fcr Anwendungsprotokolle Angaben zu Zeitpunkt, Ort, Akteur und Ereignis sowie Kennungen, die zusammengeh\u00f6rige Vorg\u00e4nge verbinden. Zugangstoken, Passw\u00f6rter und unn\u00f6tige sensible Inhalte geh\u00f6ren nicht ungesch\u00fctzt in Fehlerprotokolle.<\/p>\n\n

F\u00fcr die Revision kommt die fachliche Erkl\u00e4rung hinzu. Im Beispiel muss nachvollziehbar sein, dass V3 best\u00e4tigt wurde, bei Eingang aber bereits V4 vorlag und deshalb keine automatische Freigabe der neuen Fassung erfolgte. Eine sp\u00e4tere wirksame Entscheidung zu V4 muss davon getrennt erkennbar sein.<\/p>\n\n

Fehlerbehandlung vor der Abnahme pr\u00fcfen<\/h2>\n\n

Die beschriebenen F\u00e4lle lassen sich in einen Abnahmetest \u00fcbertragen. Dazu wird dieselbe R\u00fcckmeldung zweimal zugestellt, eine alte Best\u00e4tigung nach einer Versions\u00e4nderung \u00fcbermittelt, eine Zustellung unterbrochen, eine nicht berechtigte Rolle verwendet und eine ung\u00fcltige Referenz gesendet.<\/p>\n\n

F\u00fcr jeden Fall sind Ausgangsstand, erwartete Reaktion, tats\u00e4chliches Ergebnis und ausgel\u00f6ste Nacharbeit zu dokumentieren. Ma\u00dfgeblich ist auch der fachliche Endzustand. Ein technischer Erfolgsstatus allein zeigt nicht, ob die Freigabe korrekt angewendet oder zu Recht zur\u00fcckgewiesen wurde.<\/p>\n\n

Der Test belegt ausschlie\u00dflich den gepr\u00fcften Umfang. Er ersetzt keine dauerhafte \u00dcberwachung und best\u00e4tigt nicht automatisch andere Schnittstellen oder sp\u00e4tere Konfigurationsst\u00e4nde.<\/p>\n\n

Anforderungen und Produktnachweise sind dabei auseinanderzuhalten. Die Ailance-Website beschreibt eine anpassbare Plattform f\u00fcr vernetzte GRC-Prozesse. Daraus l\u00e4sst sich jedoch nicht ableiten, dass eine bestimmte Teams-Integration s\u00e4mtliche beschriebenen Fehlerf\u00e4lle abdeckt. Diese Eigenschaften sind f\u00fcr die konkrete L\u00f6sung und Konfiguration nachzuweisen.<\/p>\n\n

Organisatorische Bedeutung der Webhook-Fehlerbehandlung<\/h2>\n\n

Eine Freigabe bleibt nur dann nachvollziehbar, wenn erkennbar ist, wer welche Fassung unter welchen Voraussetzungen best\u00e4tigt hat und welche Wirkung daraus entstanden ist. Im Beispiel darf die doppelte R\u00fcckmeldung zu V3 keine ungepr\u00fcfte Freigabe von V4 ausl\u00f6sen.<\/p>\n\n

F\u00fcr Unternehmen sind deshalb neben der Schnittstelle auch Zust\u00e4ndigkeiten, Versionsbezug, Berechtigungspr\u00fcfung und der Umgang mit offenen Fehlerf\u00e4llen zu regeln. Die beschriebene Pr\u00fcflogik ist eine Architektur- und Prozessempfehlung. Sie begr\u00fcndet weder eine eigenst\u00e4ndige gesetzliche Vorgabe noch eine Produktgarantie.<\/p>\n\n

Fragen und Antworten<\/h2>\n\n

Was passiert, wenn eine Freigabe mehrfach \u00fcbertragen wird?<\/h3>\n

Eine doppelt eingehende R\u00fcckmeldung darf keine zus\u00e4tzliche fachliche Wirkung ausl\u00f6sen. Daf\u00fcr muss das System erkennen, ob dieselbe Entscheidung bereits verarbeitet wurde, und den Freigabeauftrag sowie den gespeicherten Bearbeitungsstand pr\u00fcfen.<\/p>\n\n

Darf eine Freigabe f\u00fcr eine \u00e4ltere Version automatisch auf eine neue Version \u00fcbertragen werden?<\/h3>\n

Nein. Bezieht sich die Entscheidung auf Version V3, w\u00e4hrend bereits Version V4 vorliegt, muss die urspr\u00fcngliche Freigabe mit ihrem Versionsbezug erhalten bleiben. Die aktuelle Fassung ist gesondert zu pr\u00fcfen.<\/p>\n\n

Reicht eine erfolgreiche technische Zustellung als Nachweis f\u00fcr eine g\u00fcltige Freigabe?<\/h3>\n

Nein. Eine erfolgreiche \u00dcbertragung belegt lediglich den technischen Empfang. Zus\u00e4tzlich m\u00fcssen unter anderem Freigabeauftrag, Version, Berechtigung und fachliche G\u00fcltigkeit der Entscheidung gepr\u00fcft werden.<\/p>\n\n

Welche Berechtigungen sollten bei einer Freigabe gepr\u00fcft werden?<\/h3>\n

Vor der wirksamen Verarbeitung sollten Identit\u00e4t, aktuelle Berechtigung, Mandant, Freigabeauftrag und Version gepr\u00fcft werden. Eine Anmeldung \u00fcber Microsoft 365 oder die Sichtbarkeit einer Teams-Aufgabe reicht daf\u00fcr allein nicht aus.<\/p>\n\n

Wann ist ein erneuter \u00dcbertragungsversuch sinnvoll?<\/h3>\n

Ein Retry kann bei vor\u00fcbergehenden technischen Fehlern sinnvoll sein. Fachliche Probleme wie eine fehlende Berechtigung oder eine veraltete Entscheidungsgrundlage werden durch eine erneute \u00dcbertragung jedoch nicht behoben.<\/p>\n\n

Welche Fehlerf\u00e4lle sollten bei Governance-Workflows getestet werden?<\/h3>\n

Zu den relevanten Testf\u00e4llen geh\u00f6ren doppelte R\u00fcckmeldungen, versp\u00e4tete Best\u00e4tigungen nach einer Versions\u00e4nderung, fehlende R\u00fcckmeldungen, unberechtigte Aktionen und nicht eindeutig zuordenbare R\u00fcckmeldungen. F\u00fcr jeden Fall sollten erwartete Reaktion, tats\u00e4chliches Ergebnis und der fachliche Endzustand dokumentiert werden.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t