GitHub Support Comes to Power Platform Source Control

Facebook
Twitter
LinkedIn

Last updated: August 2026 | Data checked: August 2026

Power Platform’s native source control integration has worked with exactly one Git provider since it launched: Azure DevOps. For any organization whose engineering team already lives on GitHub, that’s meant either running a separate, Azure DevOps-only ALM process for Power Platform or bolting on manual export/import workflows. Microsoft’s 2026 release wave 1 plan changes that: GitHub is being added as a supported Git provider, with public preview scheduled for August 2026 (Microsoft Learn, 2026 release wave 1).

Key Takeaways

  • 01 – What changed. Power Platform’s native source control integration now supports GitHub as a Git provider, not just Azure DevOps. Public preview begins August 2026; no general availability date has been set.
  • 02 – Who gets it. The feature rolls out automatically to admins, makers, marketers, and analysts – there’s no opt-in action required to receive access once preview lands, per Microsoft’s release notes.
  • 03 – It’s an extension, not a replacement. Existing Azure DevOps-based source control connections are unaffected. Both Azure DevOps and GitHub integrations also get unspecified performance, reliability, and new public API improvements in this same wave.
  • 04 – Why it matters commercially. GitHub hosts over 630 million repositories and 180 million-plus developers as of GitHub’s 2025 Octoverse report – a large share of the organizations Power Platform makers work alongside already keep their code there, not in Azure DevOps.
  • 05 – What to do now. Treat this as a public preview, not a production-ready capability. Pilot it in a non-critical environment once it lands; don’t move production ALM pipelines onto it before GA.

What Changed

Microsoft’s release plan entry describes the update in business terms: source control integration is “available natively within the solutions experience,” letting “citizen developers, code-first developers, and administrators” get “version control, change tracking, and seamless team collaboration across different tools and environments” (Microsoft Learn). Stripped of the marketing language, the technical change is narrow and specific: the existing native Git integration – which today only connects a Dataverse environment’s solutions to an Azure DevOps repository – is being extended to also connect to a GitHub repository.

Microsoft’s own documentation is explicit that this is additive, not a migration: “This capability is an extension of Power Platform’s native source code integration, which works with Azure DevOps Git repositories to now support GitHub as a Git provider.” The same release also promises “improved performance, reliability, and new public APIs to streamline automation” for both providers – useful for teams already running Azure DevOps pipelines, since it suggests the underlying integration is getting a broader overhaul, not just a new provider bolted on.

Public previewGeneral availability
RolloutAugust 2026Not yet scheduled
Enabled forAdmins, makers, marketers, analysts – automatically

Source: Microsoft Learn, 2026 release wave 1, published June 19, 2026, updated June 25, 2026.

Why It Matters

The business case here isn’t about Git as a technology – it’s about which Git host your organization’s engineering team actually already uses. GitHub’s 2025 Octoverse report puts the platform at over 180 million developers and 630 million repositories, with 36 million new developers added in 2025 alone (GitHub Octoverse 2025). Azure DevOps, by contrast, is a smaller, more Microsoft-shop-concentrated platform.

That gap has mattered in practice for Power Platform governance. When native source control launched as Azure DevOps-only, organizations whose broader engineering codebase already sat in GitHub faced a real choice: stand up a second, parallel Azure DevOps organization just for Power Platform ALM, or fall back to manual solution export/import – the exact “Export, Import, Go Live” pattern that skips version history, change tracking, and structured review, and that we’ve flagged as a governance gap before (see our Power Platform deployment governance checklist). This update removes that fork for any team already standardized on GitHub.

The Bigger Picture

Power Platform’s native Git integration – the ability to connect a solution directly to source control from inside the maker portal, without a separate ALM Accelerator setup – is itself a relatively recent capability. We walked through the original Azure DevOps-based setup when it shipped, covering how to connect an environment, create branches, and commit changes directly from the Solutions experience (see our Source Control: Git Integration in Power Platform walkthrough). That version remains fully supported and unchanged by this update – everything below is additive.

Microsoft’s own Power Platform ALM guidance describes a spectrum of maturity: manual solution export/import at the low end, built-in pipelines for structured environment promotion in the middle, and a full DevOps-based ALM Accelerator setup at the high end (Microsoft Learn, Choosing an ALM path). Native Git integration sits toward the higher end of that spectrum without requiring the full Accelerator setup – and extending it to GitHub means more organizations can reach that maturity level using the Git provider their engineering org already standardized on, rather than adopting a second one solely for Power Platform.

How the Integration Actually Works

In business terms: a Dataverse environment’s solutions get connected to a Git repository, so that changes made by makers in the Solutions experience can be tracked, committed, and reviewed the same way application code is.

Technically, the flow looks like this:

Maker (Solutions experience)
   -->  commits changes
Dataverse environment
   -->  source control connection
Git repository (Azure DevOps OR GitHub)
   -->  new public APIs (this release)
CI/CD automation / external tooling

The addition in this release is the second branch of that middle step – GitHub joins Azure DevOps as a valid destination – plus the new public APIs at the bottom, which matter for any team that wants to trigger builds, tests, or deployments from outside the Power Platform maker portal itself rather than relying on manual commits alone.

What’s Different Between the Two Providers Right Now

Azure DevOps integrationGitHub integration
AvailabilityGenerally availablePublic preview (Aug 2026)
Setup locationPower Platform admin center / Solutions experienceSame, once preview is enabled
Underlying capabilityVersion control, branching, commit trackingSame feature set, per Microsoft’s release notes
Recommended for production ALM todayYesNot yet – preview only

Microsoft’s standard release-plan disclaimer applies here directly: “Some of the functionality described in this release plan has not been released. Delivery timelines may change and projected functionality may not be released” (Microsoft policy). Treat the August 2026 date as a preview target, not a commitment.

Implementation Considerations

  • No action required to receive it. The release notes state this is enabled automatically for admins, makers, marketers, and analysts – there’s no admin toggle to find in advance.
  • You’ll still need a GitHub organization and repository set up, with appropriate access granted to whoever will be connecting Power Platform environments to it – the same prerequisite as the existing Azure DevOps flow, just pointed at a different provider.
  • Geographic and language availability vary. Microsoft publishes a live feature geography report and language availability report for release-wave features – check both before planning a rollout date with stakeholders.
  • Public preview means public preview. Don’t connect a production Dataverse environment’s solutions to this until it reaches general availability, for the same reason you wouldn’t put any other preview feature in your critical deployment path.

Risks and Limitations

This is a genuinely useful extension, not a finished, battle-tested capability yet. A few honest caveats:

  • No GA date is set. Microsoft’s own table lists general availability as unscheduled. Preview features can ship later than expected, change in scope, or in rare cases not ship at all.
  • The “new public APIs” are undocumented at the level of detail practitioners will want. The release plan mentions them in one sentence with no endpoint or schema detail yet – expect documentation to lag the preview.
  • This solves a provider problem, not a governance problem. Adding GitHub support doesn’t by itself fix branching strategy, review requirements, or environment promotion discipline – those still need to be designed, whichever provider you use.

AqualityCRM Analysis

Our view: this is a meaningful but narrow update, and its value depends entirely on which Git provider your organization already standardized on. If your engineering team runs on Azure DevOps, this release changes nothing for you directly beyond the promised performance and reliability improvements. If your organization’s code already lives in GitHub – which, given GitHub’s scale relative to Azure DevOps, describes a large share of the market – this closes a real gap that’s forced some clients we’ve worked with into either a second, Power-Platform-only Azure DevOps organization or a manual export/import process that undermines the governance benefits ALM is supposed to provide.

We’d recommend organizations already standardized on GitHub start a non-production pilot once public preview lands in August 2026, specifically to validate branching and review workflows before committing production solutions to it – not to wait passively for general availability. The switching cost of trying it in preview is low: it’s additive to, not a replacement for, however you’re managing ALM today.

What Businesses Should Do

  1. Identify which Git provider your Power Platform makers’ broader engineering org already uses. If it’s GitHub, this update is directly relevant; if it’s Azure DevOps, it isn’t urgent.
  2. Don’t wait for a formal announcement to check the geography and language availability reports – confirm your tenant’s region is covered before promising stakeholders a rollout date.
  3. Pilot in a sandbox or development environment first. Use the preview period to test commit, branch, and review workflows before any production solution touches it.
  4. Revisit your governance checklist. Adding a second supported Git provider is a good moment to confirm environment strategy and security roles are still correctly scoped – see our deployment governance checklist if you haven’t audited this recently.

Frequently Asked Questions

Does Power Platform support GitHub for source control today?

Not yet as of this writing. Native source control integration currently supports Azure DevOps only. GitHub support is scheduled for public preview in August 2026 as part of 2026 release wave 1, per Microsoft’s release plan.

Do I need to do anything to get access once it launches?

No admin action is required to receive the capability itself – Microsoft’s release notes state it rolls out automatically to admins, makers, marketers, and analysts. You will still need to set up a GitHub organization and repository to actually connect to.

Will this replace the existing Azure DevOps integration?

No. Microsoft describes this explicitly as an extension of the existing capability, not a replacement. Existing Azure DevOps-based source control connections continue to work unchanged.

Is this ready for production ALM pipelines?

Not yet. It’s entering public preview with no general availability date set. Microsoft’s standard release-plan disclaimer applies: delivery timelines may change and projected functionality may not ship as described.

Sources

Need help planning your Power Platform ALM strategy?

AqualityCRM can review your current environment and Git setup and recommend an approach that fits your organization’s existing engineering standards.