Eine Datenpipeline ist technisch erfolgreich gelaufen. Aber dürfen die Ergebnisse bereits in ein produktives Dataset, an den Fachbereich oder in einen Bericht gelangen? Gerade bei kritischen Daten gehört zwischen „erfolgreich verarbeitet“ und „freigegeben“ eine nachvollziehbare menschliche Entscheidung. Die Approval Activity in Microsoft Fabric Data Factory bringt diesen Kontrollpunkt direkt in den Pipeline-Ablauf.
Die neue Aktivität kann eine Pipeline anhalten, eine Freigabe über Outlook, Microsoft Teams oder einen eigenen Endpoint anfordern und erst danach die Verarbeitung fortsetzen. Für Unternehmen ist das ein nützlicher Baustein für Human-in-the-Loop-Prozesse. Aber eine Approval Activity allein ist noch kein vollständiges Berechtigungs-, Vier-Augen- oder Compliance-System. Insbesondere die Unterschiede bei rollenbasierten Freigaben sollte man kennen, bevor damit produktive Entscheidungen abgesichert werden.
Was die Approval Activity tatsächlich macht
Die Approval Activity ist eine Steuerungsaktivität in einer Fabric-Data-Factory-Pipeline. Sobald die Ausführung sie erreicht, wird eine Anfrage an die konfigurierte Freigabestelle gesendet. Die Pipeline wartet auf die Entscheidung oder darauf, dass die vorgesehene Wartezeit abläuft. Anschließend wird ein nachgelagerter Pfad ausgeführt. Die Funktion ist als Preview ausgewiesen; Teams sollten deshalb die Unterstützung im eigenen Tenant und die aktuelle Dokumentation vor einem produktiven Einsatz erneut prüfen.
Im Unterschied zu einer bloßen Benachrichtigung hat die Entscheidung direkte Konsequenzen für den Ablauf. Ein typisches Muster lautet: Daten laden und validieren, Freigabe einholen, nur bei Zustimmung die geprüfte Version zur Nutzung bereitstellen. Bei Ablehnung oder Ablauf der Wartefrist bleibt die Freigabe aus und ein definierter Fehler- oder Nacharbeitungspfad übernimmt.
Das löst eine häufige Schwachstelle klassischer Pipelines: Technisch erfolgreiche Jobs werden sonst leicht mit fachlich freigegebenen Ergebnissen verwechselt. Die Approval Activity verbindet diese zwei Schritte – ohne die fachliche Prüfung selbst übernehmen zu können.
Drei Freigabekanäle: Outlook, Teams und Custom Endpoint
Microsoft unterstützt drei Arten von Freigabeanforderungen. Die Wahl entscheidet nicht nur über den Kommunikationskanal, sondern auch darüber, welches Zugriffsmodell sich technisch absichern lässt.
| Kanal | Wie die Anfrage ankommt | Worauf Teams achten müssen |
|---|---|---|
| Outlook 365 | E-Mail mit Freigabe- und Ablehnungsoption | Für diese Freigaben wird kein Role-Based Access Control (RBAC) unterstützt. |
| Microsoft Teams | Nachricht in einem Kanal oder Gruppenchat mit Freigabelinks | Auch hier unterstützt der Freigabemechanismus kein RBAC. |
| Custom Endpoint | HTTP-Anfrage an eine eigene Freigabeintegration | Für RBAC-Anforderungen ist dies der vorgesehene Weg. Authentisierung, Rollenprüfung und Protokollierung müssen in der konkreten Lösung umgesetzt und getestet werden. |
Entscheidend: Outlook- oder Teams-Benachrichtigungen ersetzen keine verlässlich geprüfte Rollenberechtigung. Wer ein formales Vier-Augen-Prinzip, getrennte Verantwortlichkeiten oder kontextabhängige Freigabeberechtigungen benötigt, muss die Anforderung entsprechend absichern. Der Custom Endpoint bietet dafür den technischen Integrationsweg, ist aber nicht automatisch eine fertige Governance-Lösung.
Bei Outlook kann die Freigabe an eine einzelne Adresse oder eine Gruppe gerichtet werden. In Teams wird der Zielkontext als Kanal oder Gruppenchat konfiguriert. Bei einem Custom Endpoint wird eine HTTP-Anfrage mit einer festgelegten Nutzlast an einen angebundenen Dienst gesendet. Für alle drei Varianten sollten Freigabegegenstand, Version, betroffener Datenbestand und Entscheidungskontext eindeutig sein.
Eine Approval Activity in eine Pipeline einbauen
Für einen ersten Pilot benötigt man einen Fabric-Workspace und eine darin angelegte Data-Factory-Pipeline. In der Aktivitätenauswahl wird Approval hinzugefügt. Im Tab General werden Name und Timeout konfiguriert; im Tab Settings wird zwischen Outlook 365, Teams und Custom Endpoint gewählt. Für die gewählte Variante ist die entsprechende Verbindung einzurichten.
Ein praktikabler Aufbau besteht aus fünf Schritten:
- Vorbereitung und Validierung: Die Pipeline lädt Daten in eine getrennte Staging-Zone. Technische Qualitätsprüfungen laufen vollständig durch.
- Freigabegegenstand fixieren: Die Anfrage verweist auf eine eindeutige Dataset-, Tabellen- oder Artefaktversion mit den relevanten Prüfergebnissen. Sie sollte nicht nur „Bitte freigeben“ enthalten.
- Approval Activity konfigurieren: Freigabestelle, beschreibender Titel, Verbindungsdetails und eine begrenzte Wartezeit festlegen.
- Ausgänge verbinden: Der Erfolgspfad führt nur die erlaubte Freigabeaktion aus. Der Fehlerpfad hält die Bereitstellung an und dokumentiert Ablehnung oder Fristablauf.
- Testen: Zustimmung, Ablehnung, Timeout und unerwartete technische Fehler getrennt durchspielen, bevor der Prozess produktive Daten verändern darf.
Eine leicht zu übersehende Eigenschaft: Als Requestor gilt laut Produktdokumentation automatisch die Person, die die Pipeline zuletzt geändert hat. Für Teams mit getrennten Rollen ist das wichtig. Pipeline-Änderungen müssen deshalb genauso kontrolliert werden wie die eigentliche Freigabedefinition.
Approved, Rejected und Timeout richtig modellieren
Die Activity kennt zwei technische Ergebniswege: einen Erfolgsweg bei Zustimmung und einen Fehlerweg bei Ablehnung. Läuft der eingestellte Timeout ab, wird die Activity als fehlgeschlagen behandelt und folgt ebenfalls dem Fehlerweg. Ein Timeout ist damit keine stillschweigende Genehmigung. Fachlich sind „aktiv abgelehnt“ und „nicht rechtzeitig entschieden“ dennoch unterschiedliche Ereignisse und sollten im nachgelagerten Monitoring unterscheidbar bleiben.
Der Erfolgsweg darf nicht pauschal „alles veröffentlichen“ bedeuten. Er sollte exakt die zuvor geprüfte Version freischalten. Wird zwischen Prüfung und Zustimmung erneut in die Staging-Tabelle geschrieben, muss ein Versionsvergleich verhindern, dass versehentlich ein veränderter Stand freigegeben wird. Dieser zusätzliche Prüfschritt ist ein empfohlenes Umsetzungsmuster und keine automatisch bereitgestellte Funktion der Approval Activity.
Auch der Fehlerweg verdient Aufmerksamkeit. Bei Rejected sollte eine konkrete Nacharbeit mit Verantwortlichem und erneutem Prüfbedarf ausgelöst werden. Bei Timeout kann eine Erinnerung oder Eskalation sinnvoll sein; der alte Lauf sollte dabei nicht durch unkontrollierte Wiederholungen zu doppelten Schreibvorgängen führen. Bleibt die Freigabe aus, ist der sichere Standard: keine produktive Bereitstellung.
Vier-Augen-Prinzip und Separation of Duties: die kritische Grenze
Eine menschliche Entscheidung ist erst dann ein belastbarer Kontrollpunkt, wenn klar ist, wer was unter welchen Bedingungen freigeben darf. Genau hier liegt der Unterschied zwischen einem komfortablen Freigabelink und einem abgesicherten Governance-Prozess.
Für eine produktive Kontrollstrecke sollte das Team mindestens drei Rollen definieren: den Ausführenden, der Daten und Prüfung vorbereitet; den fachlichen oder technischen Reviewer, der einen konkret bezeichneten Stand beurteilt; und die freigebende Instanz, deren Entscheidung die produktive Aktion autorisiert. Diese Rollen können je nach Risiko unterschiedlich besetzt sein. Bei sensiblen Änderungen darf dieselbe Person nicht allein den Prüfgegenstand verändern und sich die Bereitstellung selbst bestätigen.
Outlook und Teams unterstützen bei dieser Activity ausdrücklich kein RBAC für Approvals. Das ist kein nebensächlicher Hinweis. Ein Team, das damit revisionssichere Vier-Augen-Freigaben verspricht, würde mehr behaupten, als die dokumentierte Funktion gewährleistet. Für Berechtigungsanforderungen ist der Custom Endpoint vorgesehen – inklusive eigener, überprüfbarer Identitäts-, Rollen- und Kontextprüfung.
Ein guter Kontrollvertrag beantwortet diese Fragen: Welche Objekt-ID und Version werden freigegeben? Welche Prüfungen sind obligatorisch? Wer ist laut Berechtigungsmodell zum Zeitpunkt der Entscheidung autorisiert? Ist der Reviewer unabhängig vom letzten Bearbeiter? Und welche Belege bleiben nach dem Lauf erhalten? Erst dann kann eine Zustimmung zuverlässig einer konkreten Änderung zugeordnet werden.
Praxisfall: Geprüfte Daten in ein produktives Reporting übernehmen
Angenommen, ein Unternehmen bereitet täglich neue Vertriebsdaten für ein Power-BI-Reporting auf. Die Datenübernahme läuft stabil, aber die Fachabteilung möchte Ausreißer kontrollieren, bevor eine neue Version freigegeben wird. Ein sinnvoller Ablauf sieht so aus:
Die Pipeline schreibt zunächst in eine Staging-Tabelle. Danach kontrolliert sie Zeilenanzahl, Dubletten, Nullwerte in Schlüsselfeldern und ausgewählte fachliche Kennzahlen. Die Prüfergebnisse werden zusammen mit dem eindeutigen Stand gespeichert. Ist eine Prüfung hart fehlgeschlagen, darf die Pipeline gar keine Freigabe anfordern: Der Vorgang geht direkt in die Fehlerbehandlung.
Sind die technischen Kontrollen erfolgreich, fordert die Approval Activity eine fachliche Entscheidung an. Der Reviewer sieht beispielsweise betroffene Periode, Datenschnitt, Abweichungen zum letzten akzeptierten Stand und die Art der bevorstehenden Bereitstellung. Eine Zustimmung erlaubt ausschließlich den geplanten Promote-Schritt für diese Version. Eine Ablehnung führt zurück zur Datenklärung; ein Timeout löst eine definierte Eskalation aus.
In einem solchen Prozess sind Datenqualitätsprüfung und Freigabe ausdrücklich getrennte Entscheidungen. Die Activity prüft keine Kennzahlen und erkennt keinen fachlichen Datenfehler; sie sorgt dafür, dass die Pipeline an einer passenden Stelle auf eine menschliche Entscheidung wartet.
Praxisfall: Riskante Schreiboperationen und Deployments absichern
Ein zweiter Anwendungsfall betrifft risikoreiche Änderungen: etwa das Austauschen einer produktiven Tabelle, das Umschalten eines konsumierten Datenbestands oder eine kontrollierte Aktivierung nach Tests. Die Approval Activity kann dabei ein ergänzendes Freigabegate vor dem tatsächlichen Write bilden.
Für reproduzierbare Deployments benötigt man allerdings mehr als einen Ja/Nein-Klick. Der freigegebene Stand sollte als unveränderlicher Release-Kandidat identifiziert sein. Die Zielumgebung muss unmittelbar vor der Aktion nochmals auf Version und Berechtigungen geprüft werden. Die Aktion selbst sollte idempotent sein oder einen dokumentierten Wiederanlauf besitzen. Bei Konkurrenzänderungen bricht der Lauf ab und holt eine neue Entscheidung ein, statt eine alte Zustimmung auf neue Daten zu übertragen.
Wie man Entwicklungs-, Test- und Produktivumgebungen über Git, Deployment Pipelines und Schnittstellen organisiert, beschreiben wir im Beitrag Microsoft Fabric CI/CD: Git, Deployment Pipelines, APIs und IaC kombinieren. Die Approval Activity ersetzt diese Release-Mechanik nicht; sie ergänzt sie um eine bewusst platzierte menschliche Freigabe.
Monitoring und Audit: Was sich nachweisen lässt
Die Activity taucht im Ausführungsverlauf der Pipeline auf. Im Monitoring Hub können offene und abgeschlossene Freigaben über den Review-Bereich bearbeitet beziehungsweise eingesehen werden. Zur jeweiligen Approval-Ausführung sind laut Dokumentation insbesondere Erstellungs- und Entscheidungszeitpunkt, Reviewer und Ergebnis nachvollziehbar.
Für operative Transparenz ist das hilfreich, aber für eine externe Audit- oder Compliance-Anforderung reicht ein UI-Eintrag nicht zwangsläufig. Teams sollten zusätzlich festhalten, welche Artefaktversion, welche Prüfergebnisse und welcher Rollenentscheid die Freigabe begründet haben. Dabei gilt: Nicht jede sichtbare Information im Monitoring Hub ist automatisch eine langfristig garantierte Audit-Aufbewahrung. Aufbewahrungsdauer, Exportierbarkeit, Manipulationsschutz und Zugriffsrechte müssen für den konkreten Anwendungsfall separat geklärt werden.
Ein minimaler Nachweisdatensatz umfasst eine korrelierbare Pipeline-Run-ID, die genaue Version des Freigabegegenstands, die fachliche Begründung, die geprüfte Reviewer-Identität, den Entscheidungszeitpunkt, das Ergebnis und den tatsächlich ausgeführten Folgepfad. Entscheidend ist die durchgehende Zuordnung von Anfrage → Entscheidung → ausgeführter Aktion.
Für laufende Fabric-Prozesse ist daneben eine Überwachung technischer Fehler nötig. Im Beitrag Operations Agent für Fabric Pipelines zeigen wir, wie sich operative Diagnose und Störungsbearbeitung von einer fachlichen Freigabe unterscheiden. Der Operations Agent darf eine fehlende Approval-Entscheidung nicht eigenmächtig ersetzen.
Typische Fehler – und wie man sie vermeidet
Unklarer Freigabegegenstand: Eine Benachrichtigung wie „Datenladung erfolgreich – bitte bestätigen“ reicht nicht. Der Reviewer braucht die Auswirkungen einer Zustimmung und eine eindeutig identifizierte Version.
Freigabe über den falschen Kanal: Outlook oder Teams sind praktisch, aber keine RBAC-gesicherte Freigabe. Bei formalen Berechtigungsanforderungen ist ein entsprechend abgesicherter Custom Endpoint einzuplanen.
Keine sichere Ablehnungsstrecke: Wenn Reject oder Timeout lediglich eine Meldung erzeugen, während ein weiterer Pfad unabhängig weiterläuft, ist das Gate wirkungslos. Die Abhängigkeiten der Pipeline müssen vorab kontrolliert werden.
Automatische Retries ohne Schutz: Eine fehlgeschlagene Folgeaktion darf nicht unkontrolliert doppelt veröffentlicht oder mehrfach geschrieben werden. Benötigt werden idempotente Aktionen, konkrete Laufkennungen und ein kontrollierter Wiederanlauf.
Preview mit Produktivgarantie verwechseln: Neue Funktionen und Integrationen können sich ändern. Daher zuerst mit nichtkritischen Daten testen, Berechtigungen prüfen und Grenzen sichtbar dokumentieren. Weder Preview noch ein erfolgreiches Demo ersetzen Betriebs-, Datenschutz- oder Revisionsanforderungen.
Wann die Approval Activity sinnvoll ist – und wann nicht
Sinnvoll ist sie für bewusst begrenzte, seltene Entscheidungsstellen mit konkreter menschlicher Verantwortung: die Freigabe einer qualitätsgeprüften Datenlieferung, eine risikoreiche produktive Aktivierung oder die fachliche Abnahme vor einer kontrollierten Datenbereitstellung. Für hochfrequente, rein technische und vollständig deterministische Verarbeitung wäre eine manuelle Zustimmung oft ein unnötiger Engpass. Dort sollten geprüfte automatische Quality Gates entscheiden.
Wichtig ist auch die Abgrenzung zu autonomen Agenten: Der Ansatz im Beitrag Project Osmos in Microsoft Fabric beschäftigt sich mit agentischer Ausführung von Data-Engineering-Aufgaben. Die Approval Activity ist dagegen ein menschlicher Kontrollpunkt in einer Pipeline – nicht der Agent, der Aufgaben selbst löst.
Bei einem gut entworfenen Freigabeprozess kann der menschliche Schritt sehr klein bleiben: Reviewer erhalten eine klare Entscheidungsgrundlage und müssen nur den wirklich risikobehafteten Übergang bestätigen. Alles Vorbereitende wird automatisch geprüft und dokumentiert.
Fazit
Die Approval Activity in Fabric Data Factory bietet einen konkreten Einstieg in Human-in-the-Loop-Pipelines: einen automatisierten Ablauf anhalten, eine menschliche Entscheidung einholen und danach den richtigen Folgepfad ausführen. Für Freigaben über Outlook oder Teams ist die fehlende RBAC-Unterstützung dabei ein entscheidender Architekturhinweis.
Wer daraus einen belastbaren Prozess machen will, braucht zusätzlich Versionstreue, klare Rollen, einen abgesicherten Freigabekanal, explizite Reject-/Timeout-Pfade und eine nachvollziehbare Dokumentation der tatsächlich ausgeführten Aktion. Die Activity ist das Gate – die Governance entsteht durch die Gestaltung des gesamten Prozesses.
Nächste Schritte
Wenn ihr Freigaben, Datenqualität und Deployment in Fabric sauber verbinden möchtet, beginnen wir am besten mit einem eng begrenzten Piloten: ein kritischer Datenfluss, ein klarer Freigabegegenstand, drei durchgespielte Ergebnisse und ein nachvollziehbarer Audit-Nachweis. Beim Microsoft Fabric Kick Start unterstützen wir euch dabei, Architektur, Verantwortlichkeiten und Umsetzung pragmatisch zusammenzubringen.
