Most Power Platform governance conversations start with what makers are allowed to build. The harder question is what happens after they build it. An app that reaches four people is a productivity win. The same app, shared to a security group of eleven thousand, is a support obligation, a data exposure surface, and a licensing conversation you did not plan for.
Managed Environments include a set of sharing controls that sit exactly at that boundary. They do not restrict who can create. They restrict how far the result can travel. Microsoft groups them under the Manage sharing section of the Managed Environments settings, and they now cover three resource families: canvas apps, solution-aware cloud flows, and agents.
This article walks through each control, what it actually enforces, the enforcement behavior that surprises most admins, and how to apply the settings at scale with PowerShell.
Where the controls live
The sharing rules are environment-scoped and are edited from the Managed Environments panel rather than from any maker-facing surface.
- Sign in to the Power Platform admin center.
- In the navigation pane, select Manage.
- In the Manage pane, select Environments.
- On the Environments page, select a managed environment.
- In the command bar, select Edit Managed Environments.
- Locate the Manage sharing section.
- Choose your settings, then select Save.
Two things follow from the location of these settings. First, the controls apply per environment, so they are a natural fit for an environment-zone model where a productivity zone carries loose limits and a business-critical zone carries tight ones. Second, they require the environment to be Managed, which means the settings are also a licensing decision.
Canvas app sharing rules
Canvas apps get a three-option model. The important detail is that the two restrictive options are dependent on each other rather than independent.
| Rule | What it does |
|---|---|
| Don’t set limits | No restriction on canvas app sharing. |
| Exclude sharing with security groups | Users cannot share canvas apps with any security group, or with everyone. |
| Limit total individuals who can be shared to | Sets a maximum number of individual users per app. This option is only available when the security group exclusion is selected. |
That dependency is the point worth internalizing. A numeric cap on individuals is meaningless while group sharing remains open, because a single group assignment routes around any per-user count. Microsoft has wired the two together so the cap can only be set on top of a closed group path.
Solution-aware cloud flow sharing rules
Cloud flows are the blunt instrument of the three. There is no graduated model and no numeric threshold. There is a single setting.
| Rule | What it does |
|---|---|
| Let people share solution-aware cloud flows (selected) | Users can share solution-aware cloud flows and agent flows with any number of individuals or security groups. |
| Let people share solution-aware cloud flows (cleared) | Users cannot share their cloud flows or agent flows with any individual or security group. |
Two scoping notes matter here. The control applies to solution-aware cloud flows, so flows living outside a solution are not governed by it, which is one more argument for the solution-first discipline you should already be enforcing. And the setting explicitly covers agent flows as well, so turning it off has a blast radius that reaches into your Copilot Studio work whether or not you intended it to.
In practice, clearing this setting is a strong move reserved for environments where flow ownership is meant to be centralized, for example a production environment where every flow runs under a service principal and co-ownership is handled through solution deployment rather than ad hoc sharing.
Agent sharing rules
The agent controls are the most granular of the three families, and they are the ones most enterprises have not yet configured deliberately. They separate the two permission levels an agent can be shared at, and then layer a group restriction and a numeric cap on top.
| Rule | What it does |
|---|---|
| Let people grant Editor permissions when agents are shared | When selected, owners and editors can share with any individual as an editor. When cleared, they cannot. This control has no effect on sharing with viewers. |
| Let people grant Viewer permissions when agents are shared | When selected, owners and editors can share with any individual as a viewer and with any security group. When cleared, they can do neither. This control does not prevent sharing with individuals as editors. |
| Only share with individuals (no security groups) | Owners and editors can share only with individuals as viewers, not with security groups. Editor sharing to individuals is unaffected. |
| Limit number of viewers who can access each agent | Sets a maximum viewer count per agent. Available only when the individuals-only setting is selected. |
The editor and viewer controls are genuinely independent, and that independence is the governance lever. Editor access is authoring access: it means someone can change an agent’s topics, instructions, knowledge sources, and actions. Viewer access is consumption. Most organizations want those two governed on completely different curves, with authoring tightly held by a named team and consumption distributed widely.
If you are configuring this for the first time, the useful starting posture in a production agent environment is editor sharing off and viewer sharing on, which produces a model where agents are authored by a controlled group and consumed by the business. Microsoft documents the underlying permission semantics in Copilot Studio security and governance.
What these rules do not do
This is the section that saves you an incident review. The enforcement model has four properties that are easy to assume incorrectly.
Rules are evaluated at the moment of sharing
Sharing rules fire when a user attempts to share. They are not a retroactive access review. Anyone who already had access to an app, flow, or agent before the rules were applied keeps that access. Setting a viewer cap of twenty on an agent already shared with four hundred people does not remove three hundred and eighty of them.
Out-of-compliance resources enter an unshare-only state
When a resource is out of compliance with a newly applied rule, the platform does not block it and does not fix it. It permits only unsharing until the resource comes back within the rule. That is a deliberate design: it stops the problem from growing while leaving remediation to a human. It also means your rollout plan needs an owner-outreach step, because nothing will resolve itself.
Enforcement can take up to an hour to begin
After you save sharing rules in the admin center, allow up to an hour before they start being enforced. Build that delay into your change window. Testing immediately after saving and concluding that the setting does not work is a common and avoidable false alarm.
Dataverse for Teams has a carve-out
In Dataverse for Teams environments, sharing rules do not affect sharing to a Team through Publish to Teams. They do apply when a user tries to share with individuals or groups in a Team other than the one bound to the environment. If your Teams estate is part of the governed surface, treat that as a documented gap rather than an oversight.
What the maker sees
When a user attempts a share that contradicts the rules, they are shown an error message rather than a silent failure. This is where governance error message content earns its place. If you have configured organization-specific error content through the PowerShell governance error message commands, that content appears inside the message the maker sees.
Use it. A generic block message produces a help desk ticket. A message that names the policy, explains the reason, and links to your intake form produces a request routed to the right place. This is one of the highest-return configuration items in the entire Managed Environments surface, and it is routinely left empty.
Applying sharing limits with PowerShell
Clicking through the admin center is fine for one environment. It is not a governance strategy for fifty. Every one of these settings is writable through the governance configuration on the environment object, which makes them scriptable, auditable, and repeatable as part of an environment provisioning routine.
The pattern is consistent across all of the examples below: retrieve the environment, read its governance configuration, add or overwrite the relevant extended setting, then save the configuration back.
Restrict canvas app sharing
This blocks security group sharing and caps individual sharing at twenty users.
# Retrieve the environment$environment = Get-AdminPowerAppEnvironment -EnvironmentName <EnvironmentId># Update the managed environment settings$governanceConfiguration = $environment.Internal.properties.governanceConfiguration$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'limitSharingMode' -Value "excludeSharingToSecurityGroups" -Force$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'maxLimitUserSharing' -Value "20" -Force# Save the updated managed environment settingsSet-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentId> -UpdatedGovernanceConfiguration $governanceConfiguration
Turn off solution-aware cloud flow sharing
# Retrieve the environment$environment = Get-AdminPowerAppEnvironment -EnvironmentName <EnvironmentId># Update the managed environment settings$governanceConfiguration = $environment.Internal.properties.governanceConfiguration$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'solutionCloudFlows-limitSharingMode' -Value "disableSharing" -Force# Save the updated managed environment settingsSet-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentId> -UpdatedGovernanceConfiguration $governanceConfiguration
Restrict agent sharing
This blocks security group sharing on agents and caps viewers at twenty.
# Retrieve the environment$environment = Get-AdminPowerAppEnvironment -EnvironmentName <EnvironmentId># Update the managed environment settings$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'bot-limitSharingMode' -Value "ExcludeSharingToSecurityGroups" -Force$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'bot-maxLimitUserSharing' -Value "20" -Force# Save the updated managed environment settingsSet-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentId> -UpdatedGovernanceConfiguration $governanceConfiguration
Note that the property names carry the historical bot- prefix from the Power Virtual Agents era. The product surface says agents. The API still says bot. Both are correct and you will need to know the mapping when you script against this.
Turn off editor sharing on agents
# Retrieve the environment$environment = Get-AdminPowerAppEnvironment -EnvironmentName <EnvironmentId># Update the managed environment settings$governanceConfiguration = $environment.Internal.properties.governanceConfiguration$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'bot-authoringSharingDisabled' -Value True -Force# Save the updated managed environment settingsSet-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentId> -UpdatedGovernanceConfiguration $governanceConfiguration
Set bot-authoringSharingDisabled to False to allow editor sharing again.
Removing limits
Reversal uses the same pattern with different values. For canvas apps, set the sharing mode to noLimit and the user cap to -1.
# Retrieve the environment$environment = Get-AdminPowerAppEnvironment -EnvironmentName <EnvironmentId># Update the managed environment settings$governanceConfiguration = $environment.Internal.properties.governanceConfiguration$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'limitSharingMode' -Value "noLimit" -Force$governanceConfiguration.settings.extendedSettings | Add-Member -MemberType NoteProperty -Name 'maxLimitUserSharing' -Value "-1" -Force# Save the updated managed environment settingsSet-AdminPowerAppEnvironmentGovernanceConfiguration -EnvironmentName <EnvironmentId> -UpdatedGovernanceConfiguration $governanceConfiguration
The same noLimit value clears the cloud flow restriction through solutionCloudFlows-limitSharingMode and the agent restriction through bot-limitSharingMode. Keeping these reversal scripts in source control alongside the restrictive ones is worth the small effort, because the day you need to unwind a setting is rarely a calm day.
A rollout pattern that works
Sharing limits fail in organizations that treat them as a switch rather than a change. A sequence that holds up:
- Measure before you restrict. Pull current sharing breadth per resource from the admin center or the Center of Excellence toolkit inventory. A cap chosen without data is either theater or an outage.
- Configure governance error content first. Do this before the rules go live so the first blocked maker gets a useful message rather than a dead end.
- Apply to one environment zone. Start where the risk is highest and the maker population is smallest, usually a production or business-critical zone rather than the default environment.
- Wait the hour, then verify. Test the block path with a real account before you announce anything.
- Run the remediation pass. Identify resources that are already out of compliance and work with owners to bring them back within the rule, since the platform will only permit unsharing until they are compliant.
- Script the final state. Move the configuration into your environment provisioning routine so the next environment inherits the posture instead of depending on someone remembering.
Where this sits in a broader governance model
Sharing limits are a distribution control, not an access control. They constrain how a maker can hand out access to something they own. They do not replace data loss prevention policies, which govern what connectors a resource can touch, and they do not replace Dataverse security roles, which govern what data a user can read once they are inside.
The three work as layers. A data policy decides what an app can reach. Sharing limits decide how many people can reach the app. Security roles decide what each of those people sees. Configure one layer and you have a gap. Configure all three per environment zone and you have a defensible posture that survives an audit.
The agent controls in particular deserve attention this quarter. Most tenants that have started building in Copilot Studio have not yet drawn the line between authoring and consumption, and the editor and viewer split in these settings is the cleanest place in the platform to draw it.
Source
Microsoft Learn: Limit sharing, Power Platform administration documentation. Settings and property names in this article reflect the documentation as published and should be verified against your tenant before you script against them.