Power Platform Governance and Administration

Currently, Power Platform Advisor provides automated recommendations with predefined severity levels (e.g., High, Medium, Low). However, there is no option for tenant admins to adjust the severity based on contextual relevance or business impact.

For example, recommendations related to license mismatches or app ownership may be marked as "High" by default, even if they pose minimal operational risk in our environment. This can lead to unnecessary escalations or misprioritization of admin efforts. I

There should be a feature in Power Platform Admin Center that allows tenant admins to:

• Override the default severity of recommendations.
• Provide justification or notes for the override.
• Track overridden recommendations separately for audit and governance purposes.

This would empower organizations to tailor the recommendation system to their unique operational context and improve the efficiency of issue triage and resolution.

when a record is deleted, the associated Business Process Flow records are permanently deleted, not sent to the recycle bin.

This behavior has caused significant challenges for our data restoration efforts. We believe this is a defect that should be addressed to support proper restoration functionality.

According to the document:https://learn.microsoft.com/en-us/troubleshoot/power-platform/dataverse/working-with-solutions/install-failure-priviledge-not-assigned#workaround, there are 3 roles that can help import solution (System Administrator, System Customizer, and Environment Maker). However, it would be better if there is an out-of-the-box role that can focus on only export and import solution and help user share the components.

When creating DLP policies for the Power Platform, having an "admin notes" section would be helpful to know why the policy made, what the exceptions are for the policy, etc. Otherwise, you are forced to remember and/or comb through the policy to know why it was made and how it differs from other policies. This would be helpful for documentation purposes as well in case I leave my position and someone needs to take over DLP management and understand why policies are created the way they are.

I’ve encountered a limitation in the Power Platform when trying to assign different access levels (read/write) for different user groups to a specific solution within a single development environment. After researching and consulting Microsoft Support, it seems this is expected behavior.

The current recommendation is to create a dedicated environment per solution. However, managing 10+ environments for separate development and testing efforts introduces significant administrative overhead and complexity.

Suggestion:

Introduce the ability to share an entire solution, including all its components (connection references, environment variables, etc.), within a single environment, similar to how Power Apps or Power Automate flows can be shared.

This would greatly improve flexibility, reduce environment sprawl, and simplify governance, especially for teams managing multiple solutions in parallel.

Am I missing a critical reason why per-solution environments are preferred or necessary?

Microsoft has been turning on new AI features, or preview features by default. Adding lots of buggy scripts or buggy functionality to our tenancy. Troubleshooting, finding and turning off this feature has become a full time job.

Simple idea,

1. Do not turn these on by default.
2. Allow the admins to turn on preview or new features when ready.
3. Provide alerts for these features. Highlight them. Making everyone aware that this exists and it is likely to cause issues.
4. If it is a mandatory update or feature. Give plenty of time & warning for testing.

Hi,

Currently, we are having the option of blocking adhoc subscription for the whole tenant with the PowerShell command:

Set-MsolCompanySettings -AllowAdHocSubscriptions $false

However, this setting affects the whole tenant. We should have another setting that allows users to block subscriptions only for specific users/groups.

Description:

We are experiencing 3 –4 repeated sign-in prompts per session in our PowerApps model-driven apps, even after users are fully authenticated.

After extensive troubleshooting with Microsoft (over 10 months), we found that:

• The issue is tied to Copilot and other features like:

• Form field assistance

• Natural language grid

• useintelligenceserviceruntime

• microsoftgraphapi

• Disabling these helps, but it reduces functionality.

• Enabling third-party cookies drastically reduces the prompts, but this isn’t a feasible solution across large organizations due to security concerns and scalability issues.

⸻

Our Ask:

Microsoft should:

• Provide a native product fix to eliminate or reduce repeated sign-in prompts.

• Allow authenticated sessions to last at least 8–12 hours without re-authentication.

• Ensure modern features like Copilot don’t break authentication flow.

This is a product-level issue that needs engineering attention.

If you’re facing the same, please upvote or share your experience.

Currently, conditional access is supported for Canvas app only and it's not supported for Model-driven app. This feature is needed for many businesses security requirement

I am an IT person who supports Dynamics 365 F&O. In the old PPAC (Power Platform Admin Center), as a System Administrator, I can grant other people's access individually.

When I tried the new PPAC, I could not add a user individually. I was told that I have to add a security group. The problem is that only the Global Administrator of Power Platform can manage the user and security group. I don't think any big company wants to give the Global Administrator role to a lot of people.

I suggest to allow the System Administrator (for even one Power Platform environment) to control the user and security group.