Almanac
Microsoft/power-appsPower Platform

Consultant KB for Microsoft Power Apps: canvas apps, model-driven apps, Power Fx, data and connections, controls and UI, code and extensibility, mobile and offline, ALM and solutions, governance and security, licensing and performance, plus cross-cutting decision guides. Implementation notes, configuration decisions and the gotchas that bite on real projects. Populated by the daily author agent from the Power Apps release plans, docs repo and product blog, plus the author's own consultant notes.

power-apps/01-canvas-apps/feature-canvas-app-publishing-and-versions.md
feature-canvas-app-publishing-and-versions.mdv1 · history
CurrentApplies to CanvasUpdated last monthSource Microsoft Learn ↗

What it does

Save and publish are separate actions. Save stores your changes for editors and adds a version-history entry; publish promotes the latest saved version to the one users actually run. Version history lets you go back, and copresence or coauthoring decides what happens when two makers open the same app.

Key facts

  • Every save creates a version-history entry. Exactly one version is marked Live — that's what shared users run. Everything else is a saved draft.
  • AutoSave is on by default and saves every two minutes. It's toggled in Settings > General.
  • Save options include Save with version notes, Save as (a copy under a new name) and Download a copy (a local .msapp).
  • Versions are visible from the app list under Details > Versions. You can select an earlier version and restore it, which creates a new version rather than rewinding in place. Publish this version only appears for the latest unpublished version.
  • Restoring an app older than six months repackages it against the oldest available version, so behaviour may differ from the original.
  • Users with the app already open get two in-app notifications on publish — one that a new version is coming, one that it's ready with a Refresh action. Those notifications appear for canvas apps on web and in an iframe, but not for SharePoint customised forms, apps embedded in Teams, apps embedded in Power BI, or the Power Apps web part.
  • Copresence is the default: the first person to open the app gets editing control, everyone else is read-only and can only save a copy. A read-only maker can select Override to take control.
  • Coauthoring is per-app and turned on under Settings > Updates > New. Turning it on overrides copresence. Maximum 10 coauthors, counted across sessions or tabs, whichever limit you hit first; anyone beyond that falls back to copresence.
  • Inactive for two hours while editing and Power Apps asks whether you want to keep editing. No answer and you're moved to read-only so someone else can take over.

When to use / skip

Turn coauthoring on for a team of two or three makers working on genuinely different screens of the same app — it beats the alternative, which is people taking turns or maintaining forked copies. Leave it off for a single-maker app, because you lose undo, redo, search, save-as and the ability to open another app while someone else is in. And treat version history as a safety net, not as source control: it's per-app, it's in the environment, and it won't help you diff, branch or review. If the client needs any of that, the conversation is about solutions and pipelines, not the Versions tab.

Configuration decisions

  • Whether AutoSave stays on. It protects against a lost browser tab and it also fills version history with noise.
  • Whether coauthoring is enabled per app, and who accepts that undo goes away when it is.
  • Whether makers save with version notes as standard, since without them the version list is a wall of timestamps.
  • How releases are actually promoted — publish-in-place in one environment, or solution export and import between dev, test and production.
  • Whether a .msapp download is part of the backup routine, and where those files are kept.

Gotchas

  • The app language is locked to the locale of the first maker who opens it for editing under coauthoring. Someone joining in a different locale can produce formula errors.
  • Multiple coauthors can select and edit the same control simultaneously. There's no locking; you can overwrite each other's work in silence.
  • Undo and redo are unavailable during coauthoring, which is exactly when you most want them.
  • Known rough edges under coauthoring: renaming a control, adding AI Builder components, adding geospatial controls, copy and paste, and running a flow a coauthor just added without refreshing first.
  • Publishing is not instant for a large app, and users already in the app keep running the old version until they refresh — and in Teams, Power BI and SharePoint forms they don't even get told.
  • Coauthoring is turned off inside the Monitor tool.

Consultant notes

  • Explain the save/publish split at handover, out loud, more than once. Makers who assume save means live will ship half-finished screens to users, and makers who assume publish is automatic will wonder why nothing changed.
  • Version history is not a backup strategy. Say so plainly, and put solution export into the ALM design instead.
  • The six-month repackaging note on restore is the one clients haven't read. Do not promise a clean rollback to a year-old version.
  • If the app is embedded in Teams or Power BI, plan how users find out about a new version, because the platform won't tell them.
  • Coauthoring's 10-maker limit counts tabs. A maker with three tabs open is three of your ten.

Worth another look if coauthoring picks up undo, or if version restore behaviour on old apps changes.

Was this accurate?
Related
Canvas component libraries06-code-and-extensibilityApp sharing and ownership09-governance-and-securityApp quarantine and blocking09-governance-and-securityCopilot in Power Apps01-canvas-appsOffline for canvas apps07-mobile-and-offlineCanvas app performance01-canvas-apps