GitHub Connection Health Self-Test
Reusable child flow called at the start of every GitHub-dependent parent flow; calls Get The Authenticated User and terminates with a clear error + owner email if the connection returns 401, preventing cascade failures.
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
A lightweight, reusable child flow that verifies the GitHub connector connection is healthy before any GitHub-dependent parent flow executes its real work. It calls the GitHub connector's *Get the authenticated user* operation; if the call fails (expired token, revoked OAuth grant, reduced scope, etc.) the flow emails the configured owner and terminates with a distinct failure status, giving parent flows a clean, single-point signal to abort instead of producing misleading cascade errors downstream.
This is the child-flow pattern: wire every GitHub-dependent parent flow's first step to call this self-test; if it terminates Failed, short-circuit the parent.
Use Case
FlowLibs fleet has a growing number of flows that touch GitHub (issue triage, PR assignment, webhook provisioning, collaborator audits, etc.). When the GitHub OAuth grant expires or the consented scope changes, those parent flows fail mid-run — sometimes halfway through writing state to Dataverse or SharePoint — producing partial updates that are painful to reconcile. A one-call pre-flight test on every GitHub parent flow keeps GitHub connector authorization concerns out of each individual business flow.
Audience: IT Admins (monitoring the fleet) and Developers (building new GitHub-dependent parent flows).
The flow is ideal for teams that:
- Fails fast with a clearly-attributed error code (GitHubConnectionUnhealthy) the parent flow can branch on.
- Emails the owner a single, actionable alert (re-authorize the connection reference) instead of one alert per cascading flow run.
- Keeps GitHub connector authorization concerns out of each individual business flow.
Flow Architecture
Manually trigger a flow
Request / ButtonStandard manual trigger. Chosen so the flow can be invoked three ways: (1) called by a parent flow via Run a Child Flow (intended pattern), (2) run on demand from the Power Automate portal for ad-hoc health checks, or (3) wired to a Recurrence-style wrapper if the team wants a daily standalone heartbeat.
Initialize varOwnerEmail
Initialize variable (String)Reads the `flowlibs_OwnerNotificationEmail` environment variable into a flow-scoped string variable. Putting it in a variable gives downstream actions a clean, consistent reference and makes it trivial to swap the env var implementation without editing every consumer action.
Scope: Try GitHub Connection
ScopeWraps the probe in a Scope so the parent flow can reason about the probe as a single unit regardless of how the underlying action succeeds or fails. The Scope acts as a try-block — it completes (Succeeded or Failed), and the next Condition inspects `result('Scope_Try_GitHub_Connection')` to decide what to do. Nested inside: Get Authenticated GitHub User (GitHub connector `GetUser`) — the actual probe `GET /user` against the GitHub REST API. Succeeds when the connection reference is authorized and the OAuth token is still valid; fails (401/403) when the token is expired, revoked, or missing required scopes.
Check If Connection Test Failed
If conditionExpression: `first(result('Scope_Try_GitHub_Connection'))?['status']` equals `"Failed"`. The `result()` workflow function returns the full action-run metadata array for every child action inside the Scope, including status, error code, error message, and name. This lets us inspect the probe outcome without relying on outputs from the GitHub action (which won't exist if the call failed).
- Send Alert Email to Owner — Outlook 365 `SendEmailV2` — HTML email to the owner summarising the first failed action: name, status, error code, and error message pulled directly from `result(...)`. Importance = High.
Environment Variables
| Schema name | Type | Default | Description |
|---|---|---|---|
| flowlibs_OwnerNotificationEmail | String | you@yourcompany.com | Recipient for the connection-failure alert email. Swap per tenant. |
Connectors & Connections
| Connector | API name | Actions used |
|---|---|---|
| GitHub | shared_github | GetUser (Get the authenticated user — the health probe) |
| Office 365 Outlook | shared_office365 | SendEmailV2 (Send the alert email to the owner when the probe fails) |
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.
- Swap the alert recipient
- Edit the flowlibs_OwnerNotificationEmail environment variable's current value in the target environment — no flow edit required.
- Switch from Outlook to Teams for alerts
- Replace Send_Alert_Email_to_Owner with a Teams *Post message in a chat or channel* action (shared_teams, PostMessageToConversation). Keep the same result(...) expressions in the message body; add the Teams connection reference; add a Teams group/channel env var pair.
- Probe a different GitHub connection
- Update the GitHub connection reference's bound connection to the specific service account's GitHub connection. The flow logic is connection-agnostic — it always probes whatever shared_github is wired to.
- Consume from a parent flow
- In the parent flow, add a *Run a Child Flow* action at the start, select this flow from the picker, then after the child-flow action add a Condition checking outputs('Run_a_Child_Flow')['body']?['runStatus'] equals "Succeeded". If not succeeded, Terminate the parent flow or branch to a notification.
- Convert to a scheduled standalone heartbeat
- Swap the manual trigger for a Recurrence trigger (e.g., daily at 07:00 UTC). Everything else stays the same. The flow will email the owner daily only if the probe fails.
- Add additional probes (Dataverse, SharePoint, etc.)
- Duplicate the Scope_Try_GitHub_Connection block per connector, add corresponding probe actions (Dataverse ListRecords with $top=1, SharePoint GetItems
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.01Condition — detect probe failure
Detects whether the probe failed by inspecting the Scope's child-action metadata rather than attempting to read outputs from a possibly-failed action.
EXPR.02Alert email — first failed action name
First failed action name (e.g., `Get_Authenticated_GitHub_User`).
EXPR.03Alert email — action run status
Action run status — usually `Failed`.
EXPR.04Alert email — connector error code
Surfaces the connector-level error code (e.g., `Unauthorized`).
EXPR.05Alert email — connector error message
Human-readable error message from the connector.
EXPR.06Alert email — timestamp
Timestamps the alert so the owner knows when the probe ran.
EXPR.07Initialize variable — read env var
Reads the env var straight into the flow's working variable.
Comments
Sign in to join the conversation.
Sign inNo comments yet. Be the first to share your experience with this flow.