GitHub App Install - Auto-Add New Repo

Overview

This FlowLibs demo is an event-driven bridge between Dataverse and GitHub. When a new repo record is created in the flowlibs_githubrepo table, the flow fires a repository_dispatch event to an orchestrator repo so a GitHub Actions workflow can add the repo to a specific GitHub App installation — then notifies the team in Microsoft Teams.

The architecture uses a dispatch-event pattern because the GitHub connector does not expose AddSelectedRepositoryToInstallation directly. Instead of falling back to raw HTTP + PAT, the flow stays native-connector by dispatching a typed event that the orchestrator workflow handles with GitHub App credentials.

Use Case

Teams that maintain dozens of repos and use a GitHub App with *Selected repositories* installation scope have to manually check new repos into the app's repo list every time. Easy to forget. Causes broken CI, missing bot reviews, and "why is Copilot not working on this repo?" questions. This flow keeps the App's repo list in sync the moment a repo is registered in Dataverse — your source of truth.

The flow is ideal for teams that:

• Teams running GitHub Apps with the *Selected repositories* installation scope.
• Orgs that already use Dataverse as the source of truth for tracked repositories.
• Want connector-first design — no PATs or raw HTTP credentials in the flow.
• Need an audit trail in Teams of when each repo was registered.

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.

Swap Teams for Slack/Email

Replace Notify_Teams with Slack PostMessage or Outlook SendEmailV2.

Route multiple App installations

Add a choice column on the Dataverse table and a Switch that sets varInstallationId based on the selected env (Dev/Prod).

Gate by branch policy compliance

Add a GitHub SearchIssues qualifier check before dispatching to verify the repo meets org standards.

Update Dataverse on success

After dispatch, call UpdateRecord to set flowlibs_addedtoinstallation = true (add the column first).

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.

triggerOutputs()?['body/flowlibs_githubrepoid']

outputs('Get_New_Repo_Row')?['body/flowlibs_name']

parameters('flowlibs_GitHubOrchestratorOwner')

{
  "event_type": "@{variables('varEventType')}",
  "client_payload": {
    "installation_id": "@{variables('varInstallationId')}",
    "github_repo_id": "@{outputs('Get_New_Repo_Row')?['body/flowlibs_ghrepoid']}",
    "repo_full_name": "@{outputs('Get_New_Repo_Row')?['body/flowlibs_name']}"
  }
}