Cancelling Dataverse via DLP policy on the Default environment

Let’s chat about how we got there first.

In my client’s organisation the decision was made to limit Power Platform usage to just Office 365 connectors due to the complexity of the service ownership, time-consuming licensing discussions – it’s complicated! So Power Platform is only allowed as a part of the Office 365 subscription, all users in the organisation are covered by their Office licenses – no Premium, no extra costs. Happy days!

Limiting Power Platform full power is as simple as just not letting people use Premium licenses. Not for the existing stuff, but for future projects. This is where it gets complicated. But wait, there is more!

And what about the Default environment?

“Every employee in an organization that uses the Power Platform has access to the default environment.” – says Microsoft documentation. Every employee mentioned above also has a Maker role which allows them to create apps and Flows and also try Premium things.

Previously we didn’t manage the Default environment so now we’ve got all sorts of Flows and apps with the Standard and Premium connectors mix.

Now we want to start managing the Default environment and stop users from using Premium(Paid) connectors. Let’s test how it’s going to look like first to be safe!

https://learn.microsoft.com/en-us/power-platform/guidance/adoption/manage-default-environment

The first step would be to cover it with the relevant DLP policy. If you are not familiar with the concept, please read the article below:

https://learn.microsoft.com/en-us/power-platform/admin/prevent-data-loss

Let’s create a DLP policy, we called it Tier 0. In the policy, we add only allowed Office connectors to the Business bucket, keep non-blockable connectors in Non-business, and block the rest.

What we immediately notice, if we haven’t thought of before, is that Dataverse connector is non-blockable therefore it can’t be blocked and it remains “in use” just not permitted to be mixed with Business Office 365 connectors we selected. It’s a very important discovery for our further investigation.

Our Default environment has database enabled so it has Dataverse. What does adding Dataverse to Non-business connectors mean to users’ Flows and apps? Let’s have a look!

I saved the policy pointing to the test environment first as I have to do some work before I apply it to the Default environment.

I am using a Test tenant where I created a database on the Default environment as we have it in our production Default.

I created a test Flow with Dataverse and “Office” connector. I expect it to break when I apply my policy to the environment.

I would like to create a Canvas app to test what it looks like for apps. I added both “Office” and Dataverse data sources to the app.

It’s time to apply the Tier 0 DLP policy to our test Default environment.

The results of the testing are below:

Our Flow with two connectors got suspended. If you open it you will see the error message telling you why.

The app is broken too. It didn’t happen instantly as with Flows but it did happen eventually.

Does it mean we cancelled Dataverse on the Default environment?

NO!!!

For apps and Flows only using Business “Office” connectors or Non-Business Dataverse connectors, nothing is going to change.

We can’t cancel just Dataverse app or just Dataverse Flow. The rules are followed so nothing is going to change.

What about model-driven apps with Dataverse? In theory, these apps shouldn’t be affected. If your app has automation mixing connectors from Business and Non-business buckets they will break.

What about…

I think I will do a separate post about model-driven apps.

And another one exploring different possibilities of canceling things. As much as I love enabling things, making sure you have control is an important part of the adoption, surprisingly.