The Problem We Are Solving
If you've ever published what looked like a small fix to a live Power App and then heard, minutes later, that the form is broken, you know why this decision gets hard.
Version history is there, but it does not feel like help when people are inside the app and waiting. You have to decide whether to restore an older version, fix the current one and publish again, or pause users because the problem is not really an app-version issue at all.
This Briefing gives you one thing to keep nearby before that happens: an incident card for your own app. It records the restore path, the last known good version, the decision rule, and the message to send users so you are not inventing all of it under pressure.
The Short Answer
Use this decision rule:
If the app screen, form, or formula is broken and you know the last good version, restore that version and publish it. If the fix is smaller and safer than rollback, fix forward and publish. If the issue touched data, flows, permissions, connectors, or a wider outage, pause users and escalate instead of treating restore as the cure.
Three plain definitions matter:
| Term | What it means during an incident |
|---|---|
| Version | A saved entry in the app's version history. Each save creates a version-history entry. |
| Publish | The action that makes saved changes available to the users the app is shared with. Saving alone does not change what users see. |
| Restore | Selecting an older saved version and creating a new version from it. Users do not get the restored version until it is published. |
Do not think of restore as a magic undo button. It creates a new version from an older one. You still need to publish that restored version before it becomes live for users.
What Matters
What users see
| State | What shared users see |
|---|---|
| Saved but not published | They keep seeing the current live version. |
| Published | They see the new version next time they open or refresh the app. |
| Restored but not published | Editors can see the restored version. Shared users still see the previous live version. |
| Restored and published | The restored version becomes live. Users may still need to reopen or refresh. |
If users already have the app open, ask them to close and reopen or refresh after you publish. Microsoft documents in-app new-version notifications for canvas apps running on the web and in iframes. For Teams embeds specifically, no in-app new-version notification appears. The same is true for Power BI embeds, SharePoint customized forms, and the Power Apps web part. If your team accesses the app pinned in Teams, they will not see a prompt to refresh; you need to tell them directly.
The restore path to rehearse once
Check this path in calm conditions and write down any wording differences in your tenant:
- Go to
make.powerapps.comand confirm you are in the right environment. - Select
Apps. - Select your app, then select
Detailson the command bar. - Select
Versions. - Select the app version you want to restore.
- Select
Restore, then confirm withRestoreagain. - Confirm a new version was created.
- To make it live for users, select
Publish this version, then confirm. - Tell users to reopen or refresh the app.
Older-app caveat: for apps older than six months, Power Apps may repackage the app with the oldest available version and functionality may have changed. Do not assume a six-month-old restore will look exactly like the original.
Practical Options
Option 1: Restore the last good version
Use this when the broken behaviour is likely in the app itself: a screen, form, formula, control, validation rule, or navigation path changed and users are now blocked.
Restore is usually the cleaner move when three things are true:
- You know which version last worked.
- The broken behaviour is worse than temporarily losing newer changes.
- You can publish the restored version and tell users to reopen or refresh.
Do not use restore as the whole answer if bad data has already been written. Restoring the app version does not repair records that were already saved into SharePoint, Microsoft Lists, Dataverse, or another data source.
Option 2: Fix forward and publish again
Use this when the bug is small, obvious, and testable. For example, you can see the renamed field, fix the form, save, test the path, and publish the corrected version faster than you can safely restore.
Fix forward is risky when you are guessing. If you cannot reproduce the issue, cannot test the corrected screen, or feel pressure to make several edits at once, pause first. A rushed second publish can create a second incident.
Option 3: Pause and inspect
Use this when the report is vague, users may be on a stale open app, or you are not sure whether the issue is app code, data, permissions, or a flow.
Send this first:
Please pause using [screen/form/app] for now. I am checking whether this is an app-version issue, a data issue, or something wider. I will confirm whether to refresh the app or wait.
This buys you enough time to check the live version, ask one user to refresh, and inspect whether records or flows were affected.
Option 4: Escalate
Escalate when the problem is not just the app version:
- Records were written incorrectly or deleted.
- A Power Automate flow failed or sent the wrong notification.
- Users see connection, sign-in, permission, or connector errors.
- Several apps or services are affected.
- You need an admin to check Power Platform service health.
In those cases, restoring the canvas app may hide the visible symptom but leave the real problem untouched.
Your Incident Card
Fill this in before the next risky publish.
| Field | Your notes |
|---|---|
| App name | |
| Environment | |
| App owner/maker | |
| App link | |
| Main data source | |
| Critical screens/forms | |
| Current live version/date | |
| Last known good version/date | |
| How I know it was good | |
| Restore path verified on | |
| Local UI wording differences | |
| How users access the app (web/Teams/mobile) |
Restore Checklist
| Step | Action | Done |
|---|---|---|
| 1 | Go to make.powerapps.com and confirm the right environment. | [ ] |
| 2 | Select Apps. | [ ] |
| 3 | Select the app, then Details. | [ ] |
| 4 | Select Versions. | [ ] |
| 5 | Select the last known good version. | [ ] |
| 6 | Select Restore, then confirm. | [ ] |
| 7 | Confirm a new version was created. | [ ] |
| 8 | Select Publish this version, then confirm. | [ ] |
| 9 | Tell users to reopen or refresh. If they use the app in Teams, send them a message directly because Teams does not show the in-app refresh prompt. | [ ] |
Decision Rule
Complete this sentence in your own words:
If the next publish goes wrong, I will restore when __________. I will fix forward when __________. I will pause and escalate when __________.
User Message After Publish Or Restore
The corrected version is now published. Please close and reopen the app, or refresh it if you are using it in the browser. If you use the app pinned in Teams, close and reopen the Teams tab. Tell me if [specific symptom] still happens.
Evidence Notes
Use Microsoft documentation for the mechanics: what save, publish, version history, restore, live versions, and refresh behaviour mean. Use community and practitioner posts as context for why makers hit this problem, not as the authority for current product behaviour.
The restore path is source-backed, but you should still rehearse it once in your tenant. Microsoft documentation currently shows compatible routes into the app details and versions screen, and tenant UI wording can vary.
The Teams notification gap is directly documented by Microsoft: the in-app new-version notification is available for canvas apps on the web and in iframes, but not for canvas apps embedded in Microsoft Teams, Power BI, SharePoint customized forms, or the Power Apps web part. This is not a minor edge case for teams that pin their apps in Teams. It means users will keep running the old version silently until they reopen or you tell them.
The older six-month restore shorthand is not safe enough for member copy. The current Microsoft warning is more nuanced: for apps older than six months, Power Apps may repackage the app with the oldest available version, and functionality may have changed.
This card helps you choose an incident move. It does not prove the app is fixed, recover bad data, repair a failed flow, or resolve a tenant outage.
Briefing published by Collab365 Spaces, reviewed by Mark Jones on . Cite as "Restore or Fix Forward: What to Do When a Power Apps Publish Goes Wrong", Collab365 Spaces. 6 sources referenced.