Preview, Publish, and Share

1. Preview, publish, and share

Your app is built and responsive. Time to ship it. This video covers the difference between preview and publish, how versioning works, what App Checker catches before you push the button, and the permissions you assign when sharing with your team.

2. Preview versus publish

Preview and Publish look similar but do very different things. Preview, which you start by pressing F5, runs the app inside Studio for you alone, with whatever unsaved changes you have. It's a sandbox. Publish takes the current saved version and pushes it live to every user you've shared the app with. They get the new version the next time they open the app. The order is always Save first, then Publish, Publish can only publish what's been saved.

3. Version history

Every time you publish, Power Apps snapshots the current state as a new version. From your list of apps in the maker portal, open the app's details and go to the Versions tab, which lists everything you've published, when, and by whom. The version your users are running is marked Live. If you ship a broken release, you select an earlier version and restore it, and within seconds every user is back on the working build. This is one of the underrated Power Apps superpowers: treat publishing as low-risk, because you can always roll back.

4. Run App checker before you publish

You met App Checker in Chapter 3 as a development habit. In Chapter 4 it earns a second pass as the pre-publish ritual. Open it, scan both tabs, and at minimum clear the red Formulas errors before publishing. Yellow warnings and accessibility findings should also be addressed; if you ship with them open, your future-self maintaining the app inherits a backlog. The shorter the App Checker list, the smaller the surface area for bugs your users actually report.

5. Sharing

When you share an app from the maker portal, you assign each user one of two roles. Co-owner can edit the app's screens and formulas, share it with others, publish new versions, and delete the app entirely. User can open it and use it, that's it. Default everyone to User unless they need to actually edit. Reserve Co-owner for two or three trusted teammates. It's the same principle as file-share permissions, read-only by default, write access by exception.

6. What share actually does

A quick mental model. Sharing doesn't duplicate the app, there's still one app, living in your environment. Sharing grants other users access to that one app. The version they open is whatever you published most recently. Unshare and access is revoked the next time they try to open it. That's why testing in preview before publishing matters so much. Every shared user sees the latest version, not a copy you can patch separately.

7. The publish workflow

Here's the order. Save, Test in Preview, run App Checker, Publish, then Share. Each step gates the next. Save preserves your work. Preview lets you exercise the app like a user. App Checker catches errors you'd otherwise ship. Publish releases the version. Share grants access. Skip any step and you risk shipping something broken to your users. Most production teams build this into a habit, every publish goes through the same chain, every time.

8. What you'll build

In the exercises you'll preview the app end-to-end, publish it, and explore how permissions work when sharing with your team.

9. Let's practice!

Time to preview, publish, and share your app.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.