Power Apps Coauthoring: Native Editing, Git and GitHub in 2026

Several makers need to work on the same canvas app, but an old tutorial tells you to create a GitHub repository, generate a personal access token and switch on an experimental Git feature inside Power Apps.

Do not build a new process that way.

Power Apps now has native canvas-app coauthoring for simultaneous editing. Microsoft also has native Power Platform Git integration for source control, but that integration uses Azure DevOps Git and solution-aware developer environments—not a GitHub PAT pasted into the app.

GitHub still has a legitimate Power Platform ALM route through GitHub Actions. It is separate from live coauthoring.

The short answer

Use the product layers for the jobs they actually do:

Need	Current route
Several makers edit the same canvas app together	Native Power Apps coauthoring
See who is present while one person edits	Copresence
Human-readable canvas source in native environment Git	Power Platform Git integration with Azure DevOps Git
Build/export/import solution artifacts through GitHub workflows	GitHub Actions for Microsoft Power Platform
Edit canvas code with GitHub Copilot CLI or another local AI tool	Separate Microsoft preview; not a production dependency by default

You do not need GitHub for coauthoring.

Coauthoring is not source control

These two controls solve different failures.

Coauthoring lets several makers work in Power Apps Studio at the same time and see each other's presence and changes.

Source control and ALM provide history, review, controlled solution artifacts and movement between environments.

Coauthoring does not give you a safe deployment pipeline. Git does not stop two people overwriting the same control in a live editing session.

Use both when the app justifies both.

Step 1: Put the app in the right environment

Before inviting coauthors, decide where development belongs.

For an app moving beyond a personal prototype:

• use a named development environment;
• put the app and related flows inside a solution where possible;
• keep test and production separate;
• use connection references and environment variables for deployable dependencies;
• assign a business owner and technical owner;
• document who can publish and deploy.

Native Power Platform Git integration is intended for developer environments. Microsoft's Git integration overview specifically says not to connect test or production environments directly; use builds and Power Platform pipelines to create and deploy solution artifacts.

That boundary is useful even when you are not using Git yet.

Step 2: Share the app with makers as co-owners

Save and publish the app, then share it with the people who need to edit it.

In the app's Share experience, assign the appropriate makers as Co-owner. Microsoft's canvas-app sharing guidance explains that co-owners can use, edit and share an app but cannot delete it or change its owners.

App permission is only one layer.

Also share or configure the resources the app depends on:

• Dataverse tables and security roles;
• SharePoint sites/lists;
• SQL or other data-source permissions;
• flows;
• connections and connection references;
• on-premises data gateways;
• custom connectors;
• environment access and maker roles.

A maker who can open the app but cannot access its data or flow dependency will see failures that look like coauthoring problems.

Use least privilege. Do not make every coauthor an environment administrator simply to get past a missing dependency.

Step 3: Turn on native coauthoring for the app

Open the canvas app in Power Apps Studio.

Microsoft's current procedure is:

1. open Settings;
2. open Updates;
3. choose New;
4. search for coauthor;
5. turn on Coauthoring.

Use the maintained coauthoring and copresence documentation if the label moves as the product changes.

When enabled, coauthoring overrides the older copresence-only experience for that app.

Microsoft currently documents a maximum of ten coauthors or open tabs in the coauthoring session. Additional participants fall back to copresence and cannot edit or see real-time updates. Treat that as a current product limit, not a permanent design guarantee.

Step 4: Agree how the team will edit

Coauthoring is real-time, but it is not conflict-proof.

Microsoft warns that two makers can select and edit the same control at the same time and overwrite one another's changes.

Use a simple working agreement:

• one maker owns a screen or component during a work block;
• avoid renaming shared controls while another person is editing formulas that reference them;
• announce changes to app-wide variables, collections, navigation and App properties;
• agree who adds or changes flows and connectors;
• refresh after another maker adds a flow;
• pause and test before a coordinated publish;
• use a short change note or work item for every build slice.

Native presence indicators show where colleagues are working. They do not understand the semantic impact of a formula change elsewhere in the app.

Know the documented limitations

Microsoft currently lists restrictions during multi-maker editing, including unavailable Undo/Redo, Save as, search, switching authoring versions and some other commands. Coauthoring is also turned off in Monitor.

Read the current limitations before planning a large paired build. If a required operation is unavailable, coordinate a short single-editor window rather than inventing a workaround during a live session.

Step 5: Save, test and publish deliberately

Decide who is the release maker for each change set.

Before publishing:

1. ask coauthors to finish or pause their current edit;
2. save the app;
3. run App checker and resolve material issues;
4. test navigation and shared components;
5. test every changed data operation with non-admin permissions;
6. test flows and connections;
7. record the app version and change set;
8. publish through the agreed owner;
9. test the published version as a normal user.

Coauthoring reduces waiting. It does not remove the need for a release point.

Add native source control when the app needs ALM

Current native Git integration is environment- and solution-aware.

Microsoft's Dataverse Git integration setup currently requires:

• development and target environments enabled as managed environments;
• an Azure DevOps subscription and relevant user licences;
• Azure DevOps permissions to read and commit source;
• a Power Platform environment with Dataverse;
• the system administrator security role to connect or disconnect Git;
• a solution containing the app and other components.

The connection starts in the Solutions area. You choose the Azure DevOps organisation, project, repository, branch and Git folder, then connect and synchronize the intended solution.

That is not the same as the retired experimental feature that asked each maker for a GitHub repository URL and PAT.

What happens to canvas-app source

Microsoft's canvas-app source control guidance explains that:

• canvas source is stored as human-readable .pa.yaml files;
• it appears in the repository's canvas folder;
• canvas changes become available for Git commit after the app is published;
• minimal direct repository edits are supported within the documented source format.

The publish boundary is easy to miss. A maker saving a draft in Studio does not automatically create a commit-ready source change.

Use pull requests, reviewers and branch policy to match the risk of the app. Do not let direct edits to generated source become an unreviewed second authoring system.

What if your organisation uses GitHub?

GitHub can still be part of Power Platform ALM, but use the supported route.

Microsoft documents GitHub Actions for Microsoft Power Platform. Those actions can export/import solutions, perform solution checks and deploy to downstream environments.

A sensible GitHub design is:

Power Apps development environment
└── solution export/unpack
    └── GitHub repository and pull request
        └── checked solution artifact
            └── controlled deployment to test
                └── approved deployment to production

That supports source history and automated ALM. It does not make GitHub the live coauthoring engine inside Power Apps Studio.

If GitHub is mandatory, design the solution export/import and pipeline path with your platform team. Do not revive the old PAT-based Studio experiment because the repository happens to be GitHub.

GitHub Copilot CLI is a separate preview

Microsoft also documents creating and editing canvas apps with AI code-generation tools, including GitHub Copilot CLI and Claude Code.

Microsoft marks that route as preview and says preview features are not meant for production use and can have restricted functionality.

It works with a live coauthoring session, but it is not evidence that the old GitHub source-control feature returned. Treat it as a separate preview with its own security, code-review and support decision.

A practical team model

For a three-person maker team:

• Maker A owns navigation and shared components;
• Maker B owns the request screen and validation;
• Maker C owns the review screen and flow integration;
• one named maker coordinates the save/test/publish point;
• changes live in one unmanaged solution in development;
• a pull request or pipeline carries the approved solution into test;
• production receives a controlled solution artifact, not live maker edits.

For each change, record:

• work item;
• app/version;
• screens/components changed;
• data or flow dependencies changed;
• test evidence;
• reviewer;
• deployment result;
• rollback artifact/version.

That may sound less exciting than “seamless GitHub coauthoring”. It is much easier to support when something breaks.

Common failure modes

A coauthor can open the app but formulas fail

Check the data source, connector, flow and environment permissions separately. App co-owner permission does not grant access to every dependency.

Changes disappear

Check whether two makers edited the same control or app-wide property. Split ownership more clearly and use a coordinated save/test point.

The native Git option is missing

Confirm you are in the Solutions experience, using eligible managed developer environments with Dataverse, and that the administrator and Azure DevOps prerequisites are met.

Git has no canvas changes to commit

Microsoft says canvas changes become available for commit after the app is published. Confirm the app is in the connected solution and the intended change has been published in development.

The business insists on GitHub

Use solution-aware GitHub Actions or another approved ALM workflow. Do not confuse repository preference with the live coauthoring mechanism.

Frequently asked questions

Do I need GitHub to coauthor a Power Apps canvas app?

No. Native coauthoring is enabled per app in Power Apps Studio and lets several makers edit together without a GitHub repository or personal access token.

Does Power Apps native Git integration support GitHub repositories?

No. Microsoft's current native environment Git setup uses Azure DevOps Git. GitHub can still support solution-based ALM through GitHub Actions, but that is a separate workflow.

How many makers can coauthor a canvas app?

Microsoft currently documents up to ten coauthors or open tabs. Additional participants fall back to copresence and cannot edit or receive real-time updates.

Can two coauthors edit the same control safely?

They can both select and edit it, but Microsoft warns they can overwrite each other's changes. Divide work by screen or component and coordinate shared/app-wide edits.

When do canvas-app changes appear in native Git integration?

Microsoft says changes become available to commit after the canvas app is published. The source is stored as readable .pa.yaml files under the repository's canvas folder.

If your maker team needs a working agreement that survives beyond a demo, join the Power Apps Builders Space. Bring the environment model, maker roles and one conflict you need the process to prevent.