Bitbucket New Repo Provisioning and Standards

Overview

This flow ensures every new Bitbucket repository starts compliant. A developer (or an upstream Form/app) creates a Repo Request row in a Dataverse registry table. The flow picks it up, asks a platform admin to approve, and on approval creates the repository, applies the standard branch protections on main (required approvals, passing builds, no force-push), seeds a standard README, records the result in the registry, and notifies the requester and the platform Teams channel. If rejected, it marks the request and notifies without creating anything.

Why it matters: Repos created ad-hoc skip protections and conventions, accruing risk and inconsistency. Templated, approval-gated provisioning bakes in standards from commit one and leaves a governed audit trail in Dataverse.

Status: Built · Ships Off (demo). Going live requires only authorizing the connections, setting the environment variable values, and registering the upstream request intake.

Use Case

A platform/IT team wants developers to request a repository and receive a fully-configured, governed repository automatically — without a human manually clicking through Bitbucket settings each time. The Dataverse table doubles as the request intake and the repo registry/audit log.

Flow Architecture

Environment Variables

Connectors & Connections

Connector	API name	Actions used
Microsoft Dataverse	shared_commondataserviceforapps	SubscribeWebhookTrigger UpdateRecord
Approvals	shared_approvals	StartAndWaitForAnApproval
Microsoft Teams	shared_teams	PostMessageToConversation
Office 365 Outlook	shared_office365	SendEmailV2

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.

Branch patterns

Add more branch-restrictions calls for develop/release/*, or change the pattern from main.

Default reviewers

Populate flowlibs_DefaultReviewers and add a POST …/default-reviewers/{uuid} call per reviewer in the Yes branch.

Template files

The README commit is the pattern; add more …/src commits (e.g. bitbucket-pipelines.yml, CODEOWNERS) driven by a JSON flowlibs_TemplateFiles.

Language scaffolds

Branch on flowlibs_language to commit stack-specific templates.

Naming convention

Enforce a repo naming rule in Initialize Repo Slug (e.g. prepend the team).

Request intake

Point a Microsoft Form or Power App at the flowlibs_reporequest table to collect requests; the flow triggers on row creation either way.

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(triggerOutputs()?['body/flowlibs_name'],' ','-'))}

@equals(outputs('Start_Provisioning_Approval')?['body/outcome'],'Approve')

@int(variables('varRequiredApprovals'))

@{concat('https://bitbucket.org/',variables('varWorkspace'),'/',variables('varRepoSlug'))}

@{concat('message=', encodeUriComponent('Add standard README (FlowLibs governance)'), '&branch=main&README.md=', encodeUriComponent(variables('varReadmeBody')))}

@{concat('Bearer ', variables('varAccessToken'))}

Customize & download