Hy Hong Chun

We need to clarify the region restriction in Azure policy applied to resource group since we're encountering a discrepancy in the parameters in the Azure policy when creating a Billing policy in Power Platform Admin Center.

The environment we're trying to add is located in [Australia Southeast], and the resource group is under policy which allows creation of resources in [Australia East] and [Australia Southeast]. Technically, this should pass because the location meets the requirements of the policy.

However, the Azure policy return the error missing region [Australia]. And only when user add [Australia] to the policy, it will allow the creation of Biling policy for the environment which is located in [Australia Southeast].

This doesn't make sense this this mean it will allow all region in Australia and is not restricted to Australia East and Southeast. There is no documentation mentioned this part, so this doesn't make sense to the end users.

We will need a documentation or explanation for this type of scenario to avoid confusion in the future.

Currently, there is no audit for any change made to the Environment Settings in Power Platform Admin Center. So, when there is an unknown change in a setting such as 'Audit settings' for the log retention policy for an environment, we have no clue to who changed it.

All current audit features are for changes inside the environment Dataverse and access to environment. Even Azure Purview.

I'd be great if we can have an audit to record change for general Settings in Power Platform Admin Center as well.

When creating a new table, we define Display name, the Schema name will also be updated correspondingly. And this is by design.

If we define the Display name with upper-case, then the Schema name will also be defined in upper case correspondingly. And it will not match the lower-case Logical name. Because it seems that Logical name is always in lower-case by default when creating a new table and column.

In case, the Display name is defined in upper case, as long as we modify the Schema name to lower case from the beginning, then it would match the Logical name.

However, not all users will be aware of this behavior and only notice when using the schema name and logical name to develop other function.

For example, when we develop an Odata API to retrieve lookup value, if Schema name and Logical name are not the same, then it will return error. After we updated both the Logical name and Schema name to be identical, it works.

It would be a good idea if we can match Schema name and Logical name in both upper-case or lower-case when we create a new table and column automatically.

We'd like to propose feature to impose data usage limitation for individual environments instead of allowing shared capacity on Tenant level.

This is to help customer better managing their storage and capacity usage in long term instead of having to replanning the capacity management as the business grows.

Per document below, it's stated that SharePoint doesn't fully support ALM scenarios.

There are issues in correctly updating the references to SharePoint in the environment where the solution is imported. It means that SharePoint meta-data (for example, a new column has been added) or data source info (for example, a list pointed at) will be wrong. Refreshing Power Apps Studio in the target environment won't get additional metadata and the data source will always point to the data source for the source environment

Data source references based on environment variables aren't updated during solution import - Microsoft Dataverse | Microsoft Learn

Since it's not fully supported, this option should be removed and updated on the document to avoid confusion for the customer.

Per document below, it's stated that SharePoint doesn't fully support ALM scenarios.

There are issues in correctly updating the references to SharePoint in the environment where the solution is imported. It means that SharePoint meta-data (for example, a new column has been added) or data source info (for example, a list pointed at) will be wrong. Refreshing Power Apps Studio in the target environment won't get additional metadata and the data source will always point to the data source for the source environment

Data source references based on environment variables aren't updated during solution import - Microsoft Dataverse | Microsoft Learn

Since it's not fully supported, this option should be removed and updated on the document to avoid confusion for the customer.

Because the concept of device doesn’t exist for Dynamics CRM Online as far as I’m aware of, so a shared service account will take the role as a ‘device’ in this case and get assigned the device license.

And users will take turn access the Applications corresponding to the device licenses assigned to the service accounts. In the Licensing Guide, it does mention that “Device licenses may use shared logins (such as “Warehouse Computer” and a shared password) or individual logins (each user’s personal credentials), depending on the application and license.”

Currently, this is the default nature of the Device license for Dynamics CRM Online Platform.

However, this doesn't meet the requirement of some users since some companies don't allow to use Common Id (shared Id) under any circumstance. What is expected here is that each users will sign in with their own account and password instead of shared account and shared password. So, this design is flaw in this this type of scenario.

And since we don’t have any suggestion at this moment to bypass this mechanism for the device license, we hope Microsoft can adjust this design to support scenario like this.

Second deployment of Patch will fail with error "import: FAILURE: A patch cannot be imported as a holding solution".

The reason why the pipeline failed to import the second patch after the first one is due to the pipeline step of the system using StageAndUpdate, while the Power Platform pipeline defaulted to ‘Upgrade’ with Overwrite only.

Based on the article for Power Platform pipelines, "Not currently. Pipelines default import behavior is Upgrade with Overwrite customizations."

Normally, for patch, the default method should be ‘Update’ instead. And we cannot use ‘Upgrade’ for patch. However, because Power Platform pipeline only support ‘Upgrade’, it causes conflict in the import logic for patch deployment. This is currently by-design behavior

For the pipelines in Power Platform to fully function as a deployment channel, we need the Update to be included in the future to enhance user experience.

Hi team,

We'd like to request an addition of a feature to ping Sitemap navigation bar in the application instead of letting it be auto collapsed. This would help users who has larger screen with a lot of real estate and allow them to accomplish their tasks with great experience.

We hope this can be considered in future new release to enhance the user experience as there is currently no available feature yet out of the box.