Secure Human-in-the-Loop Workflows with a Copilot Studio Custom Connector
Diesen Beitrag auf Deutsch lesen
A webhook action lets Copilot Studio workflows pause for human input, resume through a custom UI, and protect callback URLs with production controls.
TL;DR
A Copilot Studio custom connector can pause a workflow through a webhook action and resume it when the backend posts to the generated notificationUrl. The flow dehydrates while waiting. The OpenAPI definition needs x-ms-notification-url, x-ms-notification-content, no x-ms-trigger, and a DELETE unsubscribe endpoint.
Original by Adi Leibowitz, on The Custom Engine. Read the original
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Use the Human-in-the-Loop connector action when built-in email or Teams responses create workflow noise, and shape the custom UI around the process.
- Admins/CoE: Replace in-memory storage and dev tunnels before production, using persistent storage and HTTPS hosting for the backend.
- Security/Compliance: Keep the SAS-signed notificationUrl server-side and add OAuth plus user authorization, because anyone with the URL can resume the flow.
Frequently asked questions
What does x-ms-notification-url do in a Copilot Studio custom connector?
It tells Power Platform to generate a callback URL and inject it into the connector request for later workflow resumption.
How does a Copilot Studio webhook action resume a paused workflow?
The backend posts the human response to notificationUrl, causing Power Platform to rehydrate the flow and continue with the response data.
How should a Human-in-the-Loop connector protect notificationUrl in production?
Keep the SAS-signed notificationUrl server-side and never expose it to browsers or end users, because anyone with it can resume the flow.