Trigger Deploy from Approval

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

Environment Variables

Connectors & Connections

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.

@json(concat('{"event_type":"', variables('varEventType'), '","client_payload":{"target_environment":"', triggerBody()['TargetEnvironment'], '","build_number":"', triggerBody()['BuildNumber'], '"}}'))

@concat('Production deployment request: BUILD ', triggerBody()['BuildNumber'], ' -> ', triggerBody()['TargetEnvironment'])