Trigger Deploy from Approval
When a manager approves a production deployment request in Approvals, fires a repository_dispatch event with target environment and build-number payload, kicking off the matching GitHub Actions workflow.
Provided as-is, without warranty of any kind. Review and test each pattern in a non-production environment before deploying it to live automations. See our Terms.
Overview
This flow lets a developer kick off a controlled production deployment with a human gate. When triggered, the user supplies the target environment, build number, and reason. An approval request is sent to the configured approver. If approved, the flow fires a repository_dispatch event into a GitHub repo (which kicks off the matching GitHub Actions workflow), then notifies a Teams channel and emails the requester. If rejected, it notifies Teams and emails the requester with the denial reason.
Use Case
Teams need a centralized, auditable way to request and approve production deployments without exposing GitHub PATs or CI/CD secrets to non-developers. This flow keeps deployment credentials inside Power Platform while letting release managers authorize a deployment with a single click in Outlook or Teams.
The flow is ideal for teams that:
- Centralizes "who can deploy" inside Approvals (Entra ID identity) instead of GitHub team membership
- Keeps the GitHub PAT inside a managed connection, never on a developer laptop
- Audit trail: the approval response, the Teams post, and the email all carry the build number and reason
- Works for any repo and any environment by swapping env var values — no flow edits required
Flow Architecture
Manual trigger (TargetEnvironment, BuildNumber, Reason)
Manually trigger a flowAccepts three text inputs from the user: target environment, build number, and reason for the deployment.
Initialize 7 variables (env-var-bound)
Initialize variable (x7)Hydrates org, repo, event_type, approver, teamsGroup, teamsChannel, and notificationRecipient from environment variables into local variables for use throughout the flow.
Start and wait for an approval
Start and wait for an approvalSends a Basic approval to the single approver defined in `flowlibs_DeployApproverEmail` and waits for the response.
If outcome == "Approve"
If conditionBranches on the approval outcome to either dispatch the deployment or notify of denial.
- Create a repository dispatch event (GitHub) — POSTs a `repository_dispatch` event to the configured GitHub repo with the event_type and a client_payload containing target_environment and build_number.
- Post message in a chat or channel (Teams) — Posts a "Deployment STARTED" notification to the configured Teams channel with the build number and target environment.
- Send an email V2 (Outlook) — Emails the notification recipient with High importance, confirming the dispatch has been triggered.
Approval rejected — announce the denial.
Environment Variables
| Schema name | Type | Default | Description |
|---|---|---|---|
| flowlibs_GitHubOrganization | String | <configure> | GitHub org or user that owns the deploy repo (e.g. your-github-org). |
| flowlibs_DeployRepositoryName | String | <configure> | Repository where the GitHub Actions workflow listens for the dispatch event. |
| flowlibs_DeployEventType | String | deploy-production | Custom `event_type` value your `on: repository_dispatch:` workflow filters on. |
| flowlibs_DeployApproverEmail | String | you@yourcompany.com | Single approver's UPN. Swap for a group or manager pattern in real use. |
| flowlibs_TeamsGroupId | String | <configure> | Target Microsoft Teams group ID for status posts. |
| flowlibs_TeamsChannelId | String | <configure> | Channel inside the target Team where status messages are posted. |
| flowlibs_NotificationRecipient | String | alerts@yourcompany.com | Email recipient for the audit notice on both approve and reject paths. |
Connectors & Connections
| Connector | API name | Actions used |
|---|---|---|
| GitHub | shared_github | CreateRepositoryDispatchEvent (Triggers the GitHub Actions workflow) |
| Approvals | shared_approvals | StartAndWaitForAnApproval (Basic approval gating the dispatch) |
| Microsoft Teams | shared_teams | PostMessageToChannel (Status post on both approve and reject) |
| Office 365 Outlook | shared_office365 | SendEmailV2 (Audit emails to requester) |
Note — All connections are referenced as solution connection references; the flow is portable between environments as long as a connection is mapped at import time.
Customization Guide
Almost every realistic variant of this flow can be implemented by changing environment variable values. A few cases require small edits inside the flow definition — those are called out explicitly below.
- Deploying to another environment
- Import the solution, set values for the seven env vars (flowlibs_GitHubOrganization, flowlibs_DeployRepositoryName, flowlibs_DeployEventType, flowlibs_DeployApproverEmail, flowlibs_TeamsGroupId, flowlibs_TeamsChannelId, flowlibs_NotificationRecipient), bind the four connection references (Approvals, GitHub, Teams, Outlook), verify the GitHub PAT has repo scope (required for dispatches), then turn the flow on.
- Add a secondary approver
- Change the Start and wait for an approval action from "Basic" to "Approvals" with manager escalation so the request can be re-routed up the chain.
- Require two approvals
- Chain a second Start and wait for an approval action after the first, both in the true branch, so two separate approvers must sign off before the dispatch fires.
- Add a Slack notification
- Insert a Slack PostMessage action after the Teams post for dual-channel coverage of the deployment status.
- Filter by environment
- Add an If condition after the approval to check @equals(triggerBody()['TargetEnvironment'], variables('varProdEnvironment')) before dispatching, so non-prod targets skip the gate.
Key Expressions
The flow is intentionally light on Power Fx / WDL gymnastics — the heaviest expressions are the branch-name concatenation and the approval outcome check. They are listed below in the order they appear in the flow.
EXPR.01Construct GitHub dispatch payload
Builds the JSON body POSTed to GitHub's `repository_dispatch` endpoint, including the event_type and a client_payload of target_environment and build_number from the trigger inputs.
EXPR.02Compose email subject
Subject line used in the audit emails, surfacing the build number and target environment at a glance.
Comments
Sign in to join the conversation.
Sign inNo comments yet. Be the first to share your experience with this flow.