New Project Repo Provisioning

Overview

When a new row is added to the custom Dataverse flowlibs_project table, this flow provisions a matching GitHub repository from a standard project template, adds the named project owner as a push-permission collaborator, writes the new repo URL back onto the originating Dataverse record, and emails the owner a styled welcome kit. End-to-end, a new project goes from "row inserted" to "repo created, collaborator invited, CRM updated, owner notified" in a single event-driven run with no manual GitHub clicks.

Use Case

Platform and engineering teams want a single "new project" entry point in Power Apps or Dataverse that bootstraps the entire GitHub project scaffold — template repo, collaborator invite, CRM-side traceability, and owner onboarding — without anyone clicking through the GitHub UI. This flow is that entry point: one Dataverse insert kicks off the whole sequence.

The flow is ideal for teams that:

• Event-driven via Dataverse SubscribeWebhookTrigger — no polling lag
• One Dataverse insert provisions repo, collaborator, CRM writeback, and welcome email
• Repo created from a standard template, so every project starts with the same scaffolding
• Collaborator invite uses raw PUT /collaborators so existing PAT works without an extra OAuth scope
• Writeback step uses runAfter: [Succeeded, Failed] so a missing GitHub login doesn't lose the repo URL on the Project record
• Slug-ifies the project name into a clean repo name 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.

Deploying to another environment

Confirm the flowlibs_project Dataverse table exists in the target environment with columns flowlibs_name, flowlibs_description, flowlibs_owneremail, flowlibs_ownergithublogin, flowlibs_reponame, flowlibs_repositoryurl (create it if missing — the solution does not ship the table). Import the solution, then set flowlibs_GitHubOwner, flowlibs_NewProjectTemplateOwner, flowlibs_NewProjectTemplateRepository, flowlibs_NewProjectDefaultPrivate, and flowlibs_GitHubPAT (PAT with repo scope). Bind Dataverse, GitHub, and Outlook connection references, re-select the flowlibs_project table on the trigger so Dataverse binds the webhook to live metadata, then turn the flow on.

Drop the PAT dependency

Replace the HTTP PUT /collaborators step with the GitHub connector's AddCollaborator action and remove the flowlibs_GitHubPAT env var. Eliminates the need to manage a Personal Access Token.

Approval gate before creation

Insert StartAndWaitForApproval after the variable-init chain and gate Create_Repository_From_Template on the Approve branch so a human signs off before a repo is provisioned.

Default branch protection + topics

Add HTTP calls after the create step hitting PUT /repos/{owner}/{repo}/topics

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.

toLower(replace(replace(replace(variables('varProjectName'), ' ', '-'), '_', '-'), '.', '-'))

equals(toLower(parameters('flowlibs_NewProjectDefaultPrivate (flowlibs_NewProjectDefaultPrivate)')), 'true')

outputs('Create_Repository_From_Template')?['body/html_url']

concat('https://api.github.com/repos/', variables('varRepoOwnerOrg'), '/', variables('varRepoName'), '/collaborators/', variables('varOwnerGitHubLogin'))

coalesce(triggerOutputs()?['body/flowlibs_description'], '')

parameters('flowlibs_GitHubPAT (flowlibs_GitHubPAT)')