Sharing Canvas Apps
Building the app is half the job — sharing it properly is the other half. Learn about permissions, publishing, embedding in Teams, and version management.
Sharing your app
Building an app is like cooking a meal. Sharing it is like setting the table.
You need to decide: Who gets to eat? Can they just eat, or can they also change the recipe? And do they have access to the ingredients (data)?
In Power Apps, sharing means giving people permission to run your app. But they also need access to the data behind it — if your app uses a SharePoint list, the users need access to that SharePoint list too.
Two roles: User vs Co-owner
When you share a canvas app, you assign one of two roles:
| Permission | User | Co-owner |
|---|---|---|
| Run the app | Yes | Yes |
| Edit the app | No | Yes |
| Share with others | No | Yes |
| Delete the app | No | Yes |
| View the app in app list | Yes | Yes |
| Manage versions | No | Yes |
| Update connections | No | Yes |
Priya shared her campaign tracker with the entire marketing team as Users. They can run the app and enter data, but they cannot change the design or share it further.
She added her assistant, Maya, as a Co-owner. Maya can edit the app, fix bugs, and share it with new team members when Priya is away.
Sharing with security groups
Instead of sharing with individuals one by one, you can share with a Microsoft Entra security group or Microsoft 365 group.
This is the recommended approach for teams:
- Create a security group called “Marketing Team”
- Share the app with that group
- When someone joins or leaves marketing, update the group — the app permissions update automatically
Exam tip: Questions about managing app access at scale usually involve security groups.
The data permission catch
This is the most important thing about sharing: sharing the app does not share the data.
When Priya shares her campaign tracker with the marketing team, they get access to the app itself. But the app reads data from a SharePoint list. If those users do not already have access to that SharePoint list, the app will show them an error.
You must ensure users have access to both:
- The app (via Power Apps sharing)
- The data sources the app uses (via each service’s own permissions)
| Data source | How users get access |
|---|---|
| SharePoint | Site or list permissions in SharePoint |
| Dataverse | Security roles assigned in the Power Platform admin centre |
| SQL Server | Database user accounts or Azure AD authentication |
| Excel on OneDrive | File sharing permissions in OneDrive |
| Outlook/Teams | Each user’s own Microsoft 365 account (implicit) |
Implicit vs explicit connections
Some connectors use implicit connections — the app runs with each user’s own credentials. If the app sends an email via Outlook, it sends from the signed-in user’s mailbox.
Other connectors use explicit connections — the app creator’s credentials are shared. This is less common and has security implications.
For the exam, know that most connectors are implicit: users authenticate with their own accounts.
Save vs Publish: they are different
A common mistake: people think saving their app makes changes live. It does not.
| Action | What happens |
|---|---|
| Save | Saves your changes to Power Apps. Only you and co-owners can see the saved version. Users still see the last published version. |
| Publish | Makes your saved changes live for all users. This is the version everyone runs. |
Think of it like writing a document:
- Save = saving your draft. Only editors see changes.
- Publish = printing and distributing. Everyone gets the new version.
Priya saves her app frequently while making changes. But she only publishes once she has tested everything and is confident it works. Her team keeps using the stable published version while she works on updates.
Version management
Every time you publish, Power Apps creates a new version. You can:
- View version history — see all published versions with timestamps
- Restore a previous version — roll back if something breaks
- Compare versions — review what changed between publishes
How Carlos recovered from a mistake
Carlos Reyes at Greenleaf Health accidentally broke his onboarding app by deleting a screen. He had already published the broken version.
He opened the version history, found the previous working version, and restored it. The broken version was replaced in under a minute. No data was lost — versions only affect the app design, not the data.
Exam tip: Version history is a safety net. Published versions are kept so you can always roll back.
Embedding apps in Teams and SharePoint
Canvas apps do not have to live only in the Power Apps player. You can embed them where people already work:
Embed in Microsoft Teams
- Add the app as a tab in a Teams channel
- Pin it to the Teams left rail for easy access
- Team members open it without leaving Teams
Embed in SharePoint
- Add the Power Apps web part to any SharePoint page
- The app renders inline on the page
- Great for departmental sites — HR portal, IT help desk, marketing dashboard
Share as a link
- Copy the app’s web link and share it via email or chat
- Users open it in a browser — no installation needed
Priya embedded her campaign tracker in the Marketing team’s Teams channel. The team accesses it daily without ever opening Power Apps separately.
🎬 Video walkthrough
Flashcards
Knowledge Check
Priya shares her canvas app with the marketing team, but users report they cannot see any campaign data. What is the most likely cause?
Carlos published a broken version of his app. How can he fix it fastest?
Which of the following are ways to make a canvas app available to users? (Select TWO)
Next up: Building model-driven apps — creating apps from tables, modifying forms and views, and sharing with security roles.