Human-in-the-Loop-Workflows mit einem Copilot-Studio-Connector absichern
Eine Webhook-Aktion pausiert Copilot-Studio-Workflows für menschliche Eingaben, setzt sie über eine eigene Oberfläche fort und verlangt Schutz für Callback-URLs.
TL;DR
Ein benutzerdefinierter Copilot-Studio-Connector kann einen Workflow mit einer Webhook-Aktion pausieren und fortsetzen, sobald das Backend an die erzeugte notificationUrl sendet. Währenddessen bleibt der Flow dehydriert. Die OpenAPI-Definition braucht x-ms-notification-url, x-ms-notification-content, kein x-ms-trigger und einen DELETE-Endpunkt zum Abbestellen.
Original von Adi Leibowitz, auf The Custom Engine. Artikel lesen
Dies ist unsere eigene Kurzfassung, keine Wiederveröffentlichung oder vollständige Übersetzung.
Bedeutung für Governance
- Makers: Nutzt die Human-in-the-Loop-Connectoraktion, wenn E-Mail oder Teams bei vielen Anfragen unübersichtlich werden, und gestaltet die eigene Oberfläche passend zum Prozess.
- Admins/CoE: Ersetzt In-Memory-Speicher und Entwicklungstunnel vor dem Produktionseinsatz durch dauerhafte Speicherung und HTTPS-Hosting.
- Security/Compliance: Haltet die SAS-signierte notificationUrl serverseitig und ergänzt OAuth sowie Benutzerautorisierung, weil jeder mit dieser URL den Flow fortsetzen kann.
Häufige Fragen
Was bewirkt x-ms-notification-url in einem benutzerdefinierten Copilot-Studio-Connector?
Die Einstellung veranlasst Power Platform, eine Callback-URL zu erzeugen und für die spätere Fortsetzung in die Connector-Anfrage einzusetzen.
Wie setzt eine Webhook-Aktion einen pausierten Copilot-Studio-Workflow fort?
Das Backend sendet die menschliche Antwort an notificationUrl, worauf Power Platform den Flow rehydriert und mit den Antwortdaten fortsetzt.
Wie sollte eine notificationUrl eines Human-in-the-Loop-Connectors geschützt werden?
Die SAS-signierte notificationUrl muss serverseitig bleiben und darf nicht im Browser oder für Endnutzer sichtbar sein, da jeder mit ihr den Flow fortsetzen kann.