Power Platform Governance and Administration

Currently, there is no functionality in the Power Platform admin center that allows you to extract only environments that were created with "Enable Dynamics 365 apps" turned on.

Having this functionality will improve user convenience.

Current behavior: In Power platform admin center , customers can the total table size of table.

Ask: In Power platform admin center, customer should be able to see table size as a split up of data size and index size

When using Privileged Identity Management to elevate to Global or Power Platform Admin by default the user is added the System admin security role for all environment, we would like a way to manage this as there are users from other departments that do not administer the Power Platform and they are added as System Admin to the environments. Currently there is no way to see a list of all Systems Admins with direct access to all environments, to view this would require accessing each environment 1 by 1 and removing the access and with multiple environments this can be very time consuming. Then we face the issue happening again when a user PIMs to either Global or Power Platform admin they are added back into the environment as System Admin, ideally we would like users to elevate to these roles to stop being added to the environments.

When wanting to change fields on the case form header, users have to use the little downward facing arrow to perform the changes. This is perceived too many clicks and to long winded by our users and we would like to have a possibility to perform changes directly in the form header. Fields like status reasons are updated hundreds of times a day, and it would be a quick win to have these fields made editable right in the header.

If the URL of the application has already been distributed as a shortcut and the owner can be changed without deleting the application, the URL will not be changed and the application can be used continuously without redistributing the URL.

There are plenty of OOB entities that take a considerable amount of dataverse capacity which is pretty expensive. In my opinion those tables should count as file storage which is cheaper since it's not real customer data but out of the box customization data that is required for the platform to operate. For example, I have 3 development environments where the "LocalizedLabel" table is taking 2GB per environment, "Attribute" table is taking over 740MB, "Plugin assembly base" is taking 500MB, "System Form Base" is taking 425MB, "Report Base" is taking 300MB, "Dependency Node Base" and "Dependency Base" are taking 245MB each, etc. Roughly 6GB per environment are dedicated to basic OOB entities that store solution component details. Some other entities have already been moved to the file store like "Solution", "Async Operation", "Web Resource Base", so I believe it's only fair to move all such entities to the file store instead of only some.

I've had a client that was forced to overwrite the entire OOB entitlement logic in the past because async operation was taking 100GB of storage to store the entitlement expiration and activation triggers. They opted with writing a service to delete the OOB triggers and expire them when the date came as Microsoft's official response was that this was by design. Then, the async operation table moved to file storage. If it was file storage from the beginning, they probably would have paid the price instead of moving to a custom solution.

Although the Microsoft 365 role "Service Support Admin" should have permission to submit support tickets to Microsoft, per this official article: About admin roles in the Microsoft 365 admin center - Microsoft 365 admin | Microsoft Learn, users with this role can submit ticket form M365 Admin Center only, but they cannot submit Power Platform tickets from Power Platform Admin Center.

From official M365 documentation from link above:

Assign the Service Support admin role as an additional role to admins or users who need to do the following in addition to their usual admin role: Open and manage service requests, View and share message center posts, Monitor service health

When user with "Service Support Admin" role try to open Power Platform Admin Center, they have access denied. As far as they cannot open PPAC, they cannot submit any tickets to Microsoft from there.

When user with "Service Support Admin" role tries to submit Power Platform ticket trough M365 Admin center, they need to use improper classification/type of the incident, which causes wrong routing of the ticket on Microsoft side, therefore, this is not acceptable workaround.

Official documentation for PPAC (Get Help + Support in Power Platform - Power Platform | Microsoft Learn) is not listing "Service Support admin" role. Any other role, which has ability to submit Power Platform tickets, has more privileges and permissions in M365 than "Service Support Admin" role.

There are many other M365 roles provided with the ability to submit Power Platform tickets to MS, although it has nothing to do with Power Platform - for example: Teams Admin, SharePoint Admin, etc. Why "Service Support Admin" is missed?

In order to improve the security, and in order to avoid of assigning unnecessary privileges and permissions to member of support teams on customer's side, please, provide M365 role "Service Support Admin" with ability to submit Power Platform tickets to Microsoft from Power Platform Admin Center or re-enable option to submit Power Platform tickets from M365 Admin center.

Thank you very much in advance.

As an admin I cannot monitor which endpoints are used in Flows built by any Pro Dev or Citizen Dev.

With endpoint configuration I can maybe limit the usage of certain endpoints but that's it and it does not yet work for all kind of connectors.

I would like to see an ootb integration between Power Automate and Application Insights so that I'am able to monitor which endpoints are used in which Flows in which environments.

Please add AsyncOperation as an input for the PowerPlatformPublishCustomizations task similar to the PowerPlatformImportSolution task. Currently, a timeout error is returned if a response from Dynamics is not received within the time limit after executing the PowerPlatformPublishCustomizations task. This makes it look like the task has failed, but it is just the response that failed within the allowed time.

While working in a Multi Session App, if you are using a custom JavaScript code applied at the Form OnLoad event will only trigger the first time you open it but when switching between the multi-session tabs changes will be lost.

Some new call should be implemented or a workarround.