What it does

Canvas apps are shared directly with users, security groups or Entra groups, as either User (run only) or Co-owner (run, edit, share). Model-driven apps aren't shared that way at all — access comes from Dataverse security roles assigned to the app. Two completely different models sitting under the same Share button.

Key facts

• Canvas permissions are User (run only) and Co-owner (run, edit, share — but not delete and not change the owner). Only the owner can delete or reassign.
• Sharing a canvas app doesn't share its data. You still have to handle the data source separately — Dataverse security roles, an Excel file on OneDrive, a gateway, connections, or the flows the app calls.
• If the app touches Dataverse, the share panel offers security roles directly, and there's an optional admin setting for app-level roles (App reader, App user, App maker, App admin). To change an assigned role you unshare and reshare.
• You can't grant Co-owner to a security group through the UI for an app created inside a solution. It's possible with Set-AdminPowerAppRoleAssignment.
• Microsoft's own guidance: use a security group once you're sharing with more than 100 users, or expect a degraded experience.
• Sharing with a Microsoft 365 group needs the group's SecurityEnabled property set to true. It's false by default for groups created outside Entra.
• Group owners don't inherit app permissions unless they're also members. This catches people constantly.
• Sharing model-driven apps doesn't send an email. You copy the web link (or mobile QR code) from Details and distribute it yourself.
• Environment Maker role holders don't need a licence to run model-driven apps.
• Power Apps respects the Dataverse Canvas App Share privilege — a user with that privilege set to None can't share canvas apps in the environment, including the default environment. Needs Dataverse present to configure.

When to use / skip

Direct user sharing is fine for a pilot with twenty people and a disaster at three hundred. Move to security groups early — before go-live, not after the first joiner-mover-leaver cycle — because retro-fitting groups onto an app that's been shared individually means auditing a list nobody has kept. For model-driven, don't fight the model: build a custom security role per functional persona and share the app with the role. Resist requests to "just give them System Administrator to get it working", which is how most of the misconfigurations in the next doc start.

Configuration decisions

• Groups or individuals, and which group the client actually maintains. A security group nobody updates is worse than a list you can see.
• Whether co-ownership is granted at all in production, or whether editing happens only in dev and arrives through a solution.
• Whether to restrict the canvas app Share privilege on Environment Maker so makers can't self-serve sharing in production.
• Who the nominated owner of each app is, and whether that's a person or a service account. Service account ownership survives a leaver; a person's doesn't.
• Whether app-level security roles (App reader / user / maker / admin) are turned on in the tenant, which gives makers a simpler set of choices at share time but removes some precision.

Gotchas

• Orphaned apps are the classic one. When a maker leaves and their account is deleted, a canvas app with no co-owner needs an admin to reassign it through the admin centre or PowerShell, and nobody discovers this until the app needs a change. Power Platform inventory can filter by owner, so you can find resources owned by leavers before they leave.
• The Owner column in Power Platform inventory shows the creator for cloud flows and agent flows, and doesn't update when ownership changes. It's reliable for apps, less so for the flows behind them.
• Once a security role is assigned to a user through the sharing panel, you can't unassign it from the sharing panel. You have to go to the admin centre.
• Sharing limits in a managed environment only bite at share time. Apps that were already over-shared stay over-shared until someone unshares them.
• A user outside the Dataverse root business unit can be shared an app with no security role, and then have the role set directly — easy to leave half-done.

Consultant notes

• Make ownership a deliverable. A one-page register of app, owner, co-owner, data sources and shared-with group costs an hour and saves a support engagement.
• Warn the client that "the maker left" is a real operational risk with a real cost, and that the mitigation is boring: service account or shared mailbox as owner, at least one co-owner, apps in solutions.
• When you're asked why a user can open the app but sees no data, the answer is almost always the data source permission rather than the share. Check the security role first.
• For model-driven, insist on custom roles built from the App Opener or Basic User template rather than copies of System Customizer. It's the difference between a role you can explain and one you can't.

---

Sticky note: recheck when app-level security roles come out of the admin-toggle stage, or if co-owner semantics change for solution-aware apps.