I’ve been working more on the back-end side of the Power Platform lately, automating environments, pipelines, and domain data population. As part of this work, I’ve been leveraging Environment Groups to set up policies that can then manage rules and restrictions in my environments from a DEV, TST, UAT, and PRD perspective.

At the core of these policies was ensuring that unmanaged code could not enter my TST, UAT, and PRD environments.

This worked great until I went to create a topic in Customer Insights and was greeted by this.

Actually, taking a step back, when running some of my data deployments to these environments (which happens to include topics), this worked great until my topics failed to go in.

Long story short, I have had to rescind the Managed Solution policy because there is a litany of exceptions to this rule that make it nearly impossible to enforce.

Specifically, to Customer Insights, the limitations are as follows;

• Journeys can’t be created and published.
• Engagement assets such as triggers can’t be created and published.
• Channel assets such as emails, forms, SMS, and push notifications can’t be created and published.

Logically thinking about this (now that I am far away from the problem at hand), this makes complete sense, as journeys create workflows when they are published, and everything in the Customer Insights model requires some level of create/publish scenario.

The full guide is here: https://learn.microsoft.com/en-us/power-platform/alm/block-unmanaged-customizations

However, all that to say, what would make this policy that much more valuable was if it could not be turned on (similarly to how it checks for unmanaged solutions in your environment before enabling) to check which modules you have installed and tell you, this is not possible.