-
Audit log for Power Platform environment Copilot settings changes
Suggested by Alex Pham (Tek Experts) – New – 0 Comments
We recently encountered a case where a customer noticed that certain Customer Copilot features had been re-enabled in their Dynamics 365 environment—without any prior notification or indication of who made the change. Upon investigation, we discovered that D365 currently lacks audit logging or tracking capabilities for these types of configuration changes.
While it’s possible that system updates or automated processes may re-enable features, customers need full transparency and traceability for all changes—especially those that could impact data access, user experience, or compliance.
Problem
There is no built-in mechanism to:
- Identify who enabled or modified a feature (user, service principal, or system process)
- Determine when the change occurred
- Understand what was changed and the before/after values
Suggested Solution
Introduce comprehensive audit logging for all feature enablement and configuration changes in Dynamics 365. This should include:
- Who made the change (user/service principal/system)
- When the change occurred
- What feature or setting was modified
- Previous and new values of the setting
Additionally:
- Make this audit data accessible via Advanced Find, Power Platform Admin Center, or Audit History
- Optionally, allow customers to configure notifications for changes to sensitive or critical feature flags
-
Unable to open the records after data is reattained as a part of long term retention policies
Suggested by Steffi Johnson – New – 1 Comments
Users are currently unable to open records by double-clicking on rows containing long-term retained data in the grid. While we understand that retained data becomes read-only, users should still be able to access and view complete records without edit permissions. This limitation is making it difficult for users to review important information stored in retained data.
-
Increase the inactivity period for developer environments
Suggested by Steffi Johnson – New – 0 Comments
As per the current policy, developer environments are automatically deleted after 30 days of inactivity. Given the impact this can have on customers, we kindly request that the inactivity period be extended to 60 days or more. This would allow customers sufficient time to review their environments and make any necessary updates.
Additionally, we’ve observed scenarios where customers have not configured Exchange Online within their environments. As a result, they do not receive email notifications regarding the automated cleanup process. To address this, could we explore the possibility of implementing warning messages within the Power Platform environment These alerts could inform users about the upcoming deletion and provide clear guidance on the steps needed to prevent it.