Enforce App Version Compliance in Power Apps

Every Power Apps maker has faced the frustration: you publish a critical update, but some users keep running an old cached version. The built‑in update bar at the top of the Power Apps player is often ignored or missed. To take back control, you can add a version gate – a splash screen that silently checks a central version registry, then either lets the user continue or blocks them with clear instructions to get the latest published version.

In this walk‑through we’ll build such a system for a fictitious building‑inspection app used by field inspectors on tablets. The pattern relies on a SharePoint list as the single source of truth, a hidden button triggered automatically, and a few screens that manage the user’s journey.

How the Version Gate Works

When a user opens the app, a splash screen runs a check against a SharePoint list that stores the current version number for that app. The app’s own version number is stored in a global variable.

• If the numbers match, the app navigates to the main screen.
• If they don’t match, it navigates to a “version outdated” screen that tells the user how to get the update (close and reopen, or reinstall if needed).

An admin toggle, placed on a hidden admin screen, lets you disable the auto‑check while you’re making changes in Power Apps Studio – otherwise the check would fire every time you open the app for editing.

Setting Up the Version Registry (SharePoint List)

The version registry is a simple SharePoint list that holds the correct version for each app you want to control.

1. Create a new SharePoint list named AppVersionRegistry (or any name you prefer).
2. Add two columns:

1. Add one row for your app:

You can add rows for other apps later – the list can serve as the single version source for all of your organisation’s apps.

Configuring the App Version Number

In Power Apps Studio, open the App object and add this formula to the OnStart property:

Set(varBuildVersion, "1.00");

The value "1.00" should match the RequiredVersion you stored in SharePoint, but note the formatting difference (two decimals). We’ll deal with that inconsistency in the check logic.

Place a small label on your splash screen to show the version to testers:

"v" & varBuildVersion

Creating the Gate Screens

We need four screens:

Admin Screen (ScreenAdmin)

Add a Toggle control named Toggle_AutoLoad. Set its Default property to true.

true

While editing the app, toggle this switch to Off so that the splash screen won’t fire the version check. Before you publish, make sure it is On.

Wiring the Version Check

Back on ScreenSplash, add a Button control named btnCheckVersion. Set its Visible property to false (users never see it).

Place this formula in the button’s OnSelect:

If(
  varBuildVersion = LookUp(
      'AppVersionRegistry',
      AppName = "Woodgrove Inspection App"
  ).RequiredVersion,
  Navigate(ScreenMain),
  Navigate(ScreenOutdated)
)

Now set the OnVisible property of ScreenSplash to automatically press the hidden button when the toggle is on:

If(
  Toggle_AutoLoad.Value,
  Select(btnCheckVersion)
)

That’s the core logic. When the splash screen appears, the toggle is checked; if it’s true, the hidden button is clicked and the version comparison runs.

Handling an Outdated App

ScreenOutdated should display a friendly but firm message:

“This app version is out of date. To continue working, close the app completely and reopen it. The latest version will be loaded automatically. If the issue persists, contact IT.”

You can also include a “Check Again” button that navigates back to ScreenSplash to re‑run the check (useful if the user already updated the app but it’s still in cache).

Admin Controls for Development

While building or editing the app, the toggle on ScreenAdmin should be Off. This prevents the automatic navigation from firing and kicking you out of the app.

When you’re ready to publish a new version, remember to:

1. Turn Toggle_AutoLoad back On.
2. Update the varBuildVersion in App.OnStart.
3. Update the RequiredVersion in the AppVersionRegistry SharePoint list.
4. Publish the app.

Common Pitfalls and Troubleshooting

• Auto‑load toggle left off – If you forget to turn it on before publishing, the version check never runs. Users will skip the gate entirely.
• Version string mismatch – "1.00" and "1.0" are not the same. Use the exact same format in your variable and in SharePoint. I recommend storing a three‑part number like "1.00" in both places.
• Cannot edit app because it navigates away – During development, set Toggle_AutoLoad to Off on the admin screen before previewing. If you already published with the gate active, you can still open Power Apps Studio – the check only runs when the app opens on a player (not in Studio).
• LookUp returns blank – Ensure the list name is wrapped in single quotes 'AppVersionRegistry' if it contains spaces, and that your AppName filter matches exactly.

Final Recommendation

This version‑gate pattern is lightweight, easy to implement, and works on any device that supports Power Apps. It doesn’t replace Mobile Device Management (MDM) or forced app updates at the OS level, but it gives you an immediate safety net for internal apps where you want to be certain that every user is on the latest published version.

Combine this with clear communication about update cycles and you’ll rarely hear “but I thought I had the newest version” again.

References

• Original approach – Matthew Devaney, “Force App Updates In Power Apps” (2021) – https://www.matthewdevaney.com/force-app-updates-in-power-apps/
• Microsoft Learn: LookUp function – https://learn.microsoft.com/en-us/power-platform/power-fx/reference/function-first-last
• Microsoft Learn: Select function – https://learn.microsoft.com/en-us/power-platform/power-fx/reference/function-select