Power Platform Governance and Administration

We don't find any automation scope in powerApps to perform it via CLI or API. Microsoft support also verified with us after several meetings, thus we kindly ask that you implement it going forward.

We don't find any automation scope in powerApps to perform it via CLI or API. Microsoft support also verified with us after several meetings, thus we kindly ask that you implement it going forward.

Every user wants their data to be secure and easy to work. G Suite and Office 365 are both cloud-based and store data in the cloud. Although users find Office 365 much better than G Suite because of many factors, the pricing of Office 365 is much cost efficient compared to G Suite, and the features of Microsoft Office 365 are better and more advanced. Therefore, users migrate G Suite mailboxes to Office 365. You can perform the migration task manually or with a third-party application. Users have to face complications in the manual method because it is not easy to perform, and thus, you have to be an expert. However, with a third-party tool like Shoviv G Suite to Office 365 Migration Tool, you do not need to have such limitations and complications.

The GUI of the software is user-friendly, which means even non-technical users can migrate G Suite mailboxes to Office 365 easily. The software maintains the integrity of data and the hierarchy of folders. You can add and migrate multiple G Suite mailboxes to Office 365 without any limitation in size. Users can schedule their migration process as per need with the given criteria.

Create permissions view on new UI and reorganise the categories so that they make sense. some stuff is under custom entities when they aren't custom but just OOTB entities. Have the row at the top fixed pane so when you scroll can clearly see which dot to click without remembering 1 - create 2 - read etc.

At present, deletion of audit history is very limited as you can only delete the oldest entry first.

For our organisation, it is a requirement to delete records that are inactive over a certain period of time. The criteria for data retention could depend on whether the customer is a citizen or a professional. When the record is deleted the audit history for the object.id deleted remains.

It would be ideal for us to have an option to enable us to delete the audit history of a record when the record is deleted.

When a new entitlement is created, the user has the ability to activate it directly in the form, but if the user wants to deactivate it, must go back to the entitlements view. The deactivate button is now only available on entity.

For an end user, this is a step backwards in functionality.

In SLAs, for example, it is possible to activate and deactivate without leaving the register.

It would be nice to have an option to break down the storage consumption of the RelevanceSearch table (known as Dataverse Search). This way it can be determined which entities/columns selected are consuming the most space and be able to take informed decisions on which ones to disable, to effectively and efficiently free up storage space, when required.

For Model-Driven Apps Views with more than 5000 records, it would be nice to have the total number of records shown instead of:

1 - 250 of 5000+

In addition, it would be nice to have a navigation button that allows to navigate to the last page showing the last 250 records in a view with more than 5000 records.

Currently in Dynamics 365, when setting the number of digits for a currency type, it must be set either system-wide or directly in the field. 

However, there is no ability to set the number of digits on a per-application basis. 

Example: For project operation, set the number of digits to 2. For sales hub, set the number of digits to 0. 

If the current setting is implemented, the same number of digits will be displayed because the referenced table is the same. 

Therefore, we would like to request the ability to set the number of digits for each application. 

Allow business process flows to be uniquely modified to hide the 'Active for' timer on the overall count.

This is due to the inability to be able to link the start of the timer to a specific row in the table, such as an initial contact date rather than the record creation date.