You've built a Canvas App that pulls data from SharePoint, formats it beautifully, and does exactly what your team needs. You've tested every screen, fixed every formula error, and you're ready to hand it off. Then you open the sharing menu and stare at a list of options you've never seen before — environments, co-owners, users, links, versions — and suddenly the finish line feels a lot farther away.
This moment trips up more Power Apps beginners than almost anything else. Building the app is the creative part. Publishing and distributing it is the operational part, and it has real consequences: share it wrong and people can't access it, share it too broadly and you've exposed sensitive data, skip version management and a bad update overwrites everyone's working experience without warning. Getting this right is what separates a toy you built in a weekend from a tool your organization actually relies on.
By the end of this lesson, you'll know exactly how Power Apps environments work and why they matter, how to publish your app and manage versions so you can roll back if something breaks, and how to share your app with individuals, groups, and your entire organization in a controlled, intentional way.
What you'll learn:
Before this lesson, you should have:
You do not need admin rights for most of what we'll cover, though a few options (like sharing with an entire organization) may require them.
Before you can publish anything, you need to understand where your app lives. In Power Apps, an environment is a container — think of it like a folder on steroids. It holds your apps, your data connections, your Dataverse tables, and your flows all together in one isolated space. More importantly, it controls who can see and use everything inside it.
Every Power Platform tenant (your company's Microsoft account) has at least one environment, called Default. When you first open Power Apps and start building, you're almost certainly working in the Default environment without realizing it. That's fine for learning, but in professional settings you'll often encounter multiple environments set up intentionally:
This separation exists so that a bug you introduce while redesigning a screen doesn't crash the app your colleagues are using at that moment. You build in Development, promote to Test for sign-off, then publish to Production. Think of it like branches in software version control — each environment is a lane, and you control when things move between lanes.
To see which environment you're currently in, go to make.powerapps.com. In the top-right corner, you'll see your environment name displayed next to a small grid or location icon. Click it to open a dropdown listing every environment you have access to. Switching environments is instant — click a different one and the apps, connections, and data shown in the left panel all change to reflect that new context.
Important: An app built in one environment cannot be directly "seen" by users browsing a different environment. If you publish in Development and your users are looking in Production, they'll find nothing. Always confirm you're in the right environment before publishing.
To move an app from one environment to another, you export it as a package from the source environment and import it into the target. We'll touch on this at the end of the lesson, but for now, understand that environment awareness is step one of successful app distribution.
This is the most common confusion among Power Apps beginners, and it costs people real frustration. Let's make it crystal clear.
When you press Save in Power Apps Studio (using the floppy disk icon or Ctrl+S), you are saving a draft. This draft is only visible to you — people who already have access to the app and open it will still see the last published version, not your draft. Saving frequently is a good habit, but it does not affect your users at all.
When you press Publish, you are promoting your current saved version to become the live version that all users see the next time they open the app. Publishing is the action that crosses the threshold from "work in progress" to "live update."
Here's a realistic scenario to make this concrete. Imagine your team uses a "Weekly Status Report" Canvas App built on a SharePoint list. On Tuesday, you start redesigning the main screen — you add a new filter, rearrange some cards, and change a label. You hit Save three times during this process. Your colleagues open the app Tuesday afternoon and see the old version, completely unaffected by your work. On Wednesday morning, you finish testing, you're satisfied, and you hit Publish. Now when your colleagues open the app Wednesday morning, they see your redesigned screen.
To publish your app:
That's it. The app is now live in its current form for anyone who has access.
Tip: Get into the habit of saving frequently during development, but publishing deliberately. Treat Publish like a deployment — something you do intentionally after testing, not as an afterthought.
Every time you publish a Canvas App, Power Apps creates a numbered version of that app and stores it. This is enormously valuable because it means that if your latest publish breaks something important, you can roll back to a previous version in minutes.
To see your app's version history:
You'll see a table listing every published version with timestamps and notes. The version currently live will be marked Live.
To restore a previous version:
The selected version becomes the new Live version immediately. Your users, the next time they reload the app, will see the restored version.
Warning: Restoring a version does not delete newer versions — they stay in the history. But the restored version does become Live right away, so only restore when you're sure. If you're uncertain, open the older version first by selecting "Edit" from the version menu to review it before committing.
One practical workflow: when you're about to make a significant structural change to your app, jot down the current version number. That way if the change goes sideways, you know exactly which version to restore without guessing.
Now comes the part that directly affects your end users. Sharing a Canvas App means granting specific people permission to open and use it. Until you share it, only you (the owner) can see it.
There are two levels of access you can grant:
For the vast majority of your users, User is the right choice. Only give Co-owner access to colleagues who are actively collaborating on development.
To share your app:
In the search box at the top of the Share panel, start typing a name, email address, or Microsoft 365 group name. Power Apps will search your organization's directory and suggest matches. Select the person or group you want.
Once you've selected someone, a row appears below showing their name. To the right of their name is a dropdown for permission level — it defaults to User. If you want to make someone a co-owner, click that dropdown and change it to Co-owner.
When you're satisfied, click Share. The people you've added will receive an email notification containing a link to the app.
Adding users one at a time is manageable for a team of five, but if you're rolling out an app to fifty colleagues it becomes tedious and error-prone. Microsoft 365 Groups (and Security Groups managed in Azure Active Directory) solve this.
When you add a Microsoft 365 Group to your app's sharing settings, every member of that group automatically gets access. Better yet, when someone joins or leaves the group, their app access updates automatically — you don't need to manually adjust Power Apps sharing every time your team changes.
A good rule of thumb: if the group already exists (say, "Finance Team" or "Sales EMEA"), use it. If you find yourself adding twenty individual emails, ask your IT admin whether a group already exists for those people.
Tip: Sharing with a group grants access to the app, but it does not automatically grant access to the underlying data sources. If your app reads from a SharePoint site, users also need to have permission to that SharePoint site. The same applies to any SQL tables, Dataverse tables, or other connectors your app uses. App sharing and data source permissions are managed separately.
This is a point beginners trip over constantly. You share the app, someone opens it, and they get a blank screen or an error message. In almost every case, the cause is that they can open the app but can't read the data it's trying to display. Always check data permissions alongside app permissions.
For some apps — a company directory, a benefits information tool, a general holiday tracker — you may want to make the app available to every person in your organization without maintaining a list of individuals or groups.
In the Share panel, look for the option labeled Everyone in [Your Organization Name]. When you check this box and click Share, anyone in your Microsoft 365 tenant who navigates to the Power Apps app or uses the direct link can open the app. They do not need an individual invitation.
Warning: Sharing with everyone is convenient but carries risk. If your app surfaces sensitive data — HR records, financial figures, personally identifiable information — sharing it company-wide is a compliance and privacy issue, not just a technical one. Only use this option for genuinely low-sensitivity, broad-interest apps. When in doubt, use groups.
Also note: sharing with your entire organization may require elevated permissions in your tenant. If the checkbox is grayed out or unavailable, contact your Power Platform administrator.
Once an app is shared, users need a way to actually open it. There are a few options, and which one you choose affects the user experience.
Option 1: Direct Link Every Canvas App has a unique URL. To find it:
https://apps.powerapps.com/play/[long-guid-string]Copy this link and send it to your users. Anyone with access can paste it into a browser and open the app immediately. You can put this link in a Teams message, a SharePoint page, an email, or anywhere else that makes sense for your team.
Option 2: Power Apps Mobile App Users who install the Power Apps mobile app on their phone or tablet will see all apps shared with them in the app's home screen. This is the best experience for field-facing apps designed for mobile use.
Option 3: Embedding in Microsoft Teams For teams that live in Microsoft Teams, you can add your Canvas App as a tab in a Teams channel. In Teams, navigate to the channel where you want to add the app, click the "+" button to add a tab, search for "Power Apps," and follow the prompts to select your app. This puts the app directly in the flow of your team's daily work — no need to navigate to a separate URL.
Option 4: Embedding in a SharePoint Page If your organization uses SharePoint as an intranet, you can embed the app in a SharePoint page using the Power Apps web part. This is excellent for apps tied to specific departmental sites.
Tip: For most knowledge worker apps, embedding in Teams or a SharePoint page dramatically improves adoption. When the app appears in a familiar context, people use it. When they have to remember and type a separate URL, they often don't.
Earlier we talked about moving apps between Development, Test, and Production environments. Here's how it works in practice.
To export an app:
.zip file downloads to your computerTo import that app into another environment:
.zip file you exportedAfter import, the app exists in the new environment, but you'll likely need to reconnect its data sources (the connections don't transfer perfectly across environments because they point to environment-specific resources). Update any SharePoint URLs, Dataverse environment references, or SQL connection strings as needed.
Let's put this all together with a short, practical exercise. You'll need an existing Canvas App in your Power Apps environment and a colleague or a second email address you can use for testing.
Exercise: Publish, Share, and Verify Access
Step 1: Confirm your environment Open make.powerapps.com and check the environment name in the top right. Note it down — this is where you'll be publishing and sharing.
Step 2: Open your app in Studio and publish it Click on your app to open it in Power Apps Studio. Make a small, visible change — add a label somewhere that reads "Version 2." Click Save, then click File → Publish to this environment → Publish this version. Close Studio.
Step 3: Check the version history Back in make.powerapps.com, find your app in the Apps list. Click the three-dot menu → Details → Versions. Confirm you can see at least two versions listed, with the newest marked Live.
Step 4: Share the app with a test user Click the three-dot menu on your app → Share. Add your colleague's email (or your second email account). Leave the permission as User. Click Share. Note the direct link from the Details panel.
Step 5: Open the app as the test user Switch to your test account or ask your colleague to open the link. Confirm they can see the app and your "Version 2" label appears.
Step 6: Restore the previous version Back in your owner account, go to Versions, find the previous version, and restore it. Refresh the app in your test account's browser. The "Version 2" label should be gone — you're now seeing the restored version.
If each of these steps works, you understand the full publish-share-version cycle.
"I published the app but users say nothing changed." Ask your users to do a hard refresh (Ctrl+Shift+R) or clear their browser cache. Power Apps caches the app locally for performance. In some cases, users need to close and fully reopen the app to get the latest published version.
"I shared the app but users get an error when they open it." Almost always a data permission issue, not an app permission issue. Check whether the user has access to the underlying data source — the SharePoint site, the SQL database, the Dataverse table. Grant data access separately from app access.
"The Publish button is grayed out." Make sure you've saved the app first. The Publish button is sometimes inactive until there's a saved draft newer than the current live version.
"I can't find the app after switching environments." Apps don't travel between environments automatically. If you built it in Default and switched to Production, it won't appear there. Switch back to the environment where you built it.
"A co-owner accidentally broke the app." Immediately go to Versions and restore the last known-good version. Then have a conversation about co-owner access — if someone doesn't need to edit the app, they should be a User, not a Co-owner.
"I shared with a group but some members can't access the app." Confirm the group type is supported. Sharing works best with Microsoft 365 Groups and Azure AD Security Groups. Distribution lists (old-style email groups) are often not recognized by Power Apps sharing. Ask your IT admin to confirm the group type.
Let's bring this together. You now understand that an environment is the container your app lives in, and that matching the right environment to the right stage of development (dev/test/prod) protects your users from work-in-progress changes. You know that saving creates a draft only you can see, while publishing makes changes live for everyone. You can manage versions to review history and roll back when something goes wrong. And you can share your app with individuals, groups, or your entire organization — with the understanding that data source permissions must be granted separately.
These aren't just administrative checkbox tasks. They're the practices that turn a one-off prototype into a tool your organization can trust, update, and maintain safely over time. A shared, published, version-managed app is a product. An app sitting unshared on your account is a draft.
Where to go next:
Learning Path: Canvas Apps 101