SharePoint Doc to GitHub PR

Overview

FlowLibs - SharePoint Doc to GitHub PR turns your SharePoint policy-docs library into a gated, review-first publishing pipeline. Whenever a markdown policy document is added or modified in the watched SharePoint library, the flow branches the target docs repository in GitHub, commits the updated file to that branch, opens a pull request, and emails the docs team a link to the PR so they can review in the familiar GitHub workflow before anything merges to the base branch.

The flow treats SharePoint as the authoring experience business users already know, and GitHub as the system of record for versioned, peer-reviewed documentation. No docs change goes live without a reviewer acknowledging it in GitHub.

Use Case

Policy and documentation teams that want SharePoint's editing experience but GitHub's review rigor.

The flow is ideal for teams that:

• Compliance teams publishing SOPs to a public docs site backed by GitHub Pages or MkDocs
• Internal knowledge bases where SMEs edit in SharePoint but engineering owns the downstream repo
• Audit-heavy environments where every doc change must produce a reviewer-signed PR artifact
• Migration away from direct-to-main doc commits toward a branch-and-review workflow

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.

Point at your own SharePoint library

Create (or choose) a document library that will hold the policy markdown files. Update flowlibs_SharePointSiteURL to the site's URL and flowlibs_DocsLibraryPath to the server-relative path of the library. Open the designer, reselect the library from the trigger's dropdown so the dynamic schema refreshes, and save.

Point at your own GitHub repo

Create a fine-grained PAT scoped to the docs repo with Contents:write and Pull Requests:write. Update flowlibs_GitHubOwner, flowlibs_DocsRepositoryName, flowlibs_DocsBaseBranch, and flowlibs_GitHubPAT. Reauthorize the shared_github connection reference as a user with push rights on the repo.

Change the notification recipient

Update flowlibs_DocsTeamEmail to a new recipient (single address, distribution list, or comma-separated list). To change the email body, edit the Send_PR_Notification_Email action — the emailMessage/Subject and emailMessage/Body parameters are the two touch-points.

Change the review cadence

The trigger's recurrence block is Minute, interval 5. Tighten to Minute 1 for near-real-time review or loosen to Hour 1 for bulk batches.

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/{FullPath}']}

@{substring(outputs('Compose_File_Relative_Path'), add(indexOf(outputs('Compose_File_Relative_Path'), variables('varDocsLibraryPath')), length(variables('varDocsLibraryPath'))))}

@{concat('docs/', replace(triggerOutputs()?['body/{FilenameWithExtension}'], ' ', '-'), '-', workflow()?['run']?['name'])}

@{coalesce(body('Get_Existing_File_On_Base_Branch')?['sha'], '')}

@{base64(triggerBody())}