Power Platform Governance and Administration

Values set in Choice-type column have a Description field.

This field does not seems to be used but could be used in model-driven apps and canvas apps to provide a tooltip explaining what a given choice represents.

This would be useful for fields where a tooltip could guide to new employees to use the appropriate value for a given record.

For example, when select something like a case type or a lead type, if the user is not sure what value to set, they can try a value and hover over the field to see the tooltip to help confirm that they have selected the appropriate type for the record.

a Power Platform Reader role, similar to Power Platform Administrator role but allows only read/view on all power platform environments

Currently, Power Pages Design Studio auto-saves changes to the live website, publishing changes live that are not yet ready! It should not function this way - but should have a clear Save / Publish distinction. Save would store the changes temporarily but not publish, while Publish would make them live.

Design Studio also does not allow you to view version history, track changes and revert to previous versions. This would be a fantastic improvement on a system edited by multiple makers.

It is surprising that we don't have the ability to edit any SEO fields whatsoever from Design Studio. Title and description should be the bare minimum. Other SEO fields like og:image should also be supported and easily editable on the page settings popup.

It should not be required to switch to Portal Management app to do things such as:

• Change the Page Template
• Set page's Publish status, or Access Control
• Edit SEO fields (title, description, image, etc)
• Edit the page's custom CSS / JS

These should be accessible from the Page's Settings field (which currently only shows name and partial URL).

Our makers spend more time editing BlogPosts on our Portals websites - for news, articles, etc, than WebPages. Currently, PowerPages only allows for editing WebPages.

The Portal Management content editor is very poor for user-friendliness. Our makers' jobs would be much easier if everything to do with editing the website's content could be in one place.

It would be ideal if you could add the ability to create and edit BlogPost entities from the PowerPages Design Studio.

As the frontend content editor has been deprecated, this is a very high priority for our organization. Thank you for your consideration.

This feature is as important as ever with the new addition of conflict detection and merge features from VSCode for the web. 

https://powerpages.microsoft.com/en-us/blog/configuring-code-components-properties-from-the-design-studio-now-available-in-public-preview/

As the intention of Web templates as components | Microsoft Learn seems to be to allow makers to reuse these components easily - one glaring omission is that Design Studio lacks the ability to add custom components (Web Templates with manifests).

Seems like it would be an easy win to add a section for Web Templates and allow developers to open in VS Code.

The conflict resolution would be great to have. 

Additional thoughts on how to make working with Web templates better.

1. In web templates section have 2 or 3 collapsible groupings 
2. Components - Items with a manifest
3. Page Templates- Templates that are related to a page template
4. Other
5. Alternatively (since a Template may be a page template and have a manifest) Just having some sort of visual indicator for if manifest is present/is related to a page template
6. Add a GUI for working with manifest of a web template. Options in the '...' 
7. View Manifest - Show a pop up with manifest details so users know what templates inputs are and can read description
8. Edit Manifest - Would be nice to have a low code way of authoring manifest so user error is reduced
9. Create Component - If the web template was not a Component open editor to add component definition 
10. Selecting a web template in '...' Create Component then allow editing the manifest with low code tools. 
11. Add way to add a template as a component in the same menu as adding 'text', 'image', 'video','button', etc. 
12. Preferably multistep process where select "Component" then a listing of components including details from manifest I am thinking something similar to when you pick a PCF control on a model driven app. (Actually adding a thumbnail to web templates would be a cool concept too for the content editors to see perhaps a preview of what they are getting) 

Credit to Eric Sutter who posted this idea 9 months ago in Power Pages Idea forum - which doesn't seem to be used by Microsoft's product team.

When we create a new Unmanaged Solution in Power Apps, it becomes visible to every Maker (System Customizer and Environment Maker roles)

When we create or add the existing objects (App, flows, Bot, Reports) to the unmanaged solution, the objects become exposed and every Maker (System Customizer and Environment Maker roles) in that environment will automatically gain CRUD permissions to the Unmanaged Solution and its objects' (App, flows, Bot, Reports) as well.

Security Concerns

• This has created a need for increased security rights over the Unmanaged Solution and its objects' (App, flows, Bot, Reports).
• This is causing more issues and fears to Makers about their Unmanaged Solution and its objects' (App, flows, Bot, Reports).

Changes Needed

• Please make the Unmanaged Solution visibility, and its Read, Update, Delete (RUD) permissions restricted to only the Solution creator and Admins in Power Platform.
• Please make the CRUD permissions for the objects' (App, flows, Bot, Reports) inside Unmanaged Solution restricted to only the Solution creator and Admins in Power Platform.

This is to make the unmanaged solution more secure and achieve an efficient ALM process

When multiple solution import/publish all requests are run at the same time an error occurs as per the following.

https://learn.microsoft.com/en-us/troubleshoot/power-platform/power-apps/solutions/cannot-import-solutions-publish-changes#workaround

The page above suggests using Azure pipelines or Github Actions to serialize the deployment actions but it would be beneficial if Dataverse had an internal queing mechanism to avoid this issue.

Right now the date format used in the Power Platform Admin Center is mm/dd/yyyy. You can see this in the overview of Environments (Created on) for example, but also in the Dataverse capacity (Last updated), Analytics, Power Pages sites (Created on), etc.

Most of the world uses a date format which makes more sense like dd-mm-yyyy or yyyy-mm-dd:

https://en.wikipedia.org/wiki/Date_format_by_country.

My request is to add an option in the Power Platform Admin Center to change this date format to one of the above.

With the "Access Connector for Dataverse and Power Platform", data can be exchanged between Microsoft Access (on-premises) and Dataverse (cloud), which is very helpful. Unfortunately, the connector does not support virtual tables of Dataverse, which is a major limitation.

Exchanging data between Dataverse virtual tables (cloud) and Microsoft Access (on-premises) and Microsoft Excel (on-premises) should also be implemented.