Power Platform Governance and Administration

 Idea Recommendation for Managing System Tables in Dataverse  

To enhance transparency and control over system tables in Dataverse, I propose a System Table Management Dashboard with built-in tools and clear visibility for users/customers to manage data, solutions, and privileges effectively.  For example we have a constantly growing WeResource Base Table, whcih we have to ope a support ticket, in order to Microsoft run a script to delete ophaneted customization records

Key Features and Benefits

1. Transparency of Data

  - Data Source Labeling:Every system table should include metadata showing:  

    - Origin of Data: Which solution (managed/unmanaged) introduced it.  

    - Purpose: A short description of its role in the system.  

  - Solution Mapping View: A dashboard that visualizes which tables and components belong to which solution,  1^st and 3^rd party customizations, solution imports and installed applications metadata.  

2. User Privileges and Rights Management 

  - Granular Permissions: Since Microsoft has defined that the relationship between a user and the data, not the application or environment owners determines access, this functionality should extend to managing system tables.  

  - Role-Based Management: Customers and administrators should have access to this functionality based on their assigned roles and rights, enabling them to:  

    - View and manage data associated with system tables.  

    - Execute cleanup tasks (e.g., removing orphaned customizations).  

  - Audit Trails: Log all changes made to system tables, including data modifications, schema updates, and deletions, ensuring secure and accountable management.  

3. Orphaned Customization Cleanup

  - Built-in Cleanup Tool: Replace the existing script-based approach with a user-friendly feature that:  

    - Identifies orphaned customizations (e.g., unused fields, orphaned records, deprecated tables).  

    - Provides a preview of items to delete, along with their impact on solutions or applications.  

    - Allows users to approve deletions directly within the Dataverse UI based on their roles and privileges.  

  - Impact Assessment: Notify users of dependencies before deletions to prevent accidental system issues.  

4. Enhanced Table Documentation

  - Each table should have a "Description Tab", where metadata like:  

    - Creation Date  

    - Last Modified Date  

    - Associated Solutions  

    - Dependency Tree (showing related tables and components)  

    - User-defined annotations  

    can be displayed.  

5. Customization Validation Reports

  - A Validation Tool to:  

    - Identify conflicting customizations across solutions.  

    - Highlight unused components for potential cleanup.  

6. Open Architecture Approach  

  - Ensure that all management tools, including cleanup functionalities, are fully accessible through APIs or Admin Center Tools, so customers can integrate them with their workflows if desired.  

  - Avoid black-box features; instead, provide clear documentation and functionalitoes and transparency on what operations the system performs.  

Implementation Roadmap*

1. Phase 1: Data Transparency on Dashboard

2. Phase 2: Cleanup and Validation  on Dashboard

3. Phase 3: Privilege Management on Dashboard

4. Phase 4: Documentation and APIs and Tools for all Funtionalities  

Expected Outcomes

- Improved Admin/User Confidence: Transparent data and solution management reduce confusion and trust issues.  

- Operational Efficiency: Built-in tools for cleanup and validation save time and reduce risks.  

- System Integrity and Compliance: Role-based access ensures users and administrators operate within defined rights, upholding system integrity and security.  It should be already like that.

By embedding these features into Dataverse and aligning them with Microsoft’s user-role-based access control model, customers and administrators will gain the functionality and transparency needed to manage their environments effectively while staying aligned with modern data governance principles.

When I decide to link my Dataverse tables to Fabric, I cannot choose which tables will be transferred. It would be great if I could choose only specific tables.

Format time of Modern Date picker is different with Time Setting in Modern Driven App. Date picker field from custom page should be followed CRM Setting.

Example, if we are living in Australia, where we are using dd/mm/yyyy time format, we can change in CRM setting to dd/mm/yyyy, but Date picker from custom page should show as dd/mm/yyyy, not mm/dd/yyyy as US time format.

The idea is specifically related to article:

https://learn.microsoft.com/en-us/power-platform/alm/form-alm

(1) It would be great to prevent the unhealthy scenario mentioned in the article. i.e., "it is not a healthy ALM practice to create multiple managed solutions from the development environment where the base solution (Solution A) is in an unmanaged state". A preventive mechanism should be in place to prevent a form to be added to an unmanaged solution if it is already included in another unmanaged solution within the same environment.

(2) The steps described in "Creating a new form and maintaining it using multiple managed solutions" is not a pragmatic solution, as it requires a separate environment to be setup/available just to make sure a change involves removing a field from a form will work in target environment.

A more robust solution without involving another environment would have been more practical.

Currently Dataverse and Model-driven app audit data for the tenant's Default environment is not available via the M365 Security and Compliance center (data accessed via these instructions - Microsoft Dataverse and model-driven apps activity logging - Power Platform | Microsoft Docs). This is a gap particularly in that there are activities that default to this environment and users generally have more ability to perform actions in this environment. It also leads to inconsistencies in being able to locate audit records and requires our audit and compliance team to have additional access into this via PPAC. We would like to see this information be included along with the data gathered from additional environments.

Based on the documentation here: https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools#create-service-principal-and-client-secret-using-powershell, the support engineer and myself conclude that the service principal created has full admin rights on the tenant.

[quote] "This PowerShell script helps creating and configuring the service principal to be used with the Microsoft Power Platform Build Tools tasks. It first registers an Application object and corresponding Service Principal Name (SPN) in AAD.

This application is then added as an administrator user to the Microsoft Power Platform tenant itself."

Since our company is both and ISV partner and a customer, the internal IT department will not provide such as service user. That user (for development/testing purposes) will also be able to administrate (and delete!) environments we're using for production purposes.

Hi team,

Please help create a button so we can export environment name and information in the environment page

I would like to be able to specify a default Document Location when multiple Document Locations exist for a record.

Security requirements require that Document Locations be separated, but if the default Document Location cannot be specified, it is meaningless and may lead to user error.