GitHub Label Change to Approval Flow

Overview

This flow demonstrates how to bridge GitHub's issue tracker with Microsoft Power Automate's native Approvals platform. Every hour the flow polls GitHub for any open issues that have been labeled with the configured trigger label (default needs-approval), launches a blocking Power Automate approval for each one, and then updates the GitHub issue based on the outcome — adding either an approved or rejected label, optionally closing the issue, posting a confirmation comment via the GitHub REST API, and emailing the requester with a styled HTML summary of the decision.

Use Case

A common pattern in engineering teams is to gate work on lightweight human review before allowing a contributor to start coding (or before letting a feature land in the changelog). GitHub Projects and Issues are the natural place to track that work, but GitHub itself does not ship a built-in approval workflow. This flow uses the Power Automate Approvals connector — which already handles email notifications, a mobile-friendly approver UI, audit history, and re-routing — and ties its outcome back to the originating GitHub issue. Developers see a single label change as their signal; reviewers receive a real Approvals card; the flow closes the loop on both sides automatically.

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.

Change the trigger label

Update the flowlibs_LabelChangeTriggerLabel environment variable. Any open issue carrying that label will be picked up on the next sweep — no JSON edit required.

Change the recurrence frequency

Edit the Recurrence_Hourly_Label_Sweep trigger. Frequency Hour/Minute/Day and any positive interval are supported. Power Automate's free tier minimum is 5 minutes for standard polling.

Route approvals to a different reviewer

Update flowlibs_ApprovalAdminEmail. The Approvals card will render with that account as the assigned approver and that account as the requestor (the demo points both at the same user).

Change approve/reject labels

Update flowlibs_LabelChangeApprovedLabel / flowlibs_LabelChangeRejectedLabel. The labels must already exist in the target GitHub repository.

Change the outcome notification recipient

Update flowlibs_LabelChangeNotifyEmail. Multiple recipients can be supplied as a semicolon-separated string.

Wire to a real GitHub webhook (optional)

For true event-driven behavior, replace the Recurrence trigger with a manual Request trigger and configure a GitHub repo webhook on issues events that POSTs to the trigger URL. Filter on action == 'labeled' and label.name == @{parameters('flowlibs_LabelChangeTriggerLabel')} inside the flow.

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.

state: "open"
labels: @variables('varTriggerLabel')

@body('Start_Approval_For_Issue')?['outcome']

@createArray(variables('varApprovedLabel'))

@createArray(variables('varRejectedLabel'))

@{concat('https://api.github.com/repos/', variables('varGitHubOwner'), '/', variables('varGitHubRepository'), '/issues/', items('For_Each_Issue_Awaiting_Approval')?['number'], '/comments')}

Authorization: @{concat('token ', variables('varGitHubPAT'))}