Power Platform environments: enable Dataverse or not?

There are many reasons why you should create dedicated environments for different scenarios of your Power Apps and Power Automate solutions development as well as usage. This is because pretty much all the Power Platform governance capabilities revolve around the environment concept.

One of the questions you’ll get asked during the environment creation process is “Create a database for this environment?”:

If you choose “Yes” then a Dataverse database will be provisioned within this environment. Now, since using the full Microsoft Dataverse is a premium feature, some of you might be asking the question “does this mean all users will require a premium license in this environment”?

That’s a very good question, since it’s not entirely clear how the existence of a Dataverse database technically affects the usage of Power Apps Canvas apps, for example. We do know that at least the security management features are different between Power Platform environments that have a database and those that are provisioned without one.

This is why we need to validate how the features work in practice and whether there is some licensing enforcement in place that could give us nasty surprises for the environment’s future usage across the organization for users with only Office 365 / Microsoft 365 licenses.

Sharing a Canvas app

Let’s start by creating an environment with a Dataverse database behind it, using the account “FF App Maker”. Then we’ll build a very simple Canvas app that is only using SharePoint as a data source. It’s important to note that we’ll do all of this from within a solution, meaning we are leveraging the underlying solution management framework built on Dataverse (originally developed for XRM).

Next we’ll go and share this app with the “FF App User” account that is only equipped with an Office 365 E3 license:

Then comes the interesting part: will FF App User be able to open the app? Let’s keep in mind that they don’t currently exist as a user in this environment’s Dataverse systemuser table. If the security model for Canvas apps would be controlled via this database exclusively, then that might cause problems. After all, as an unlicensed user account, there shouldn’t be a way for FF App User to get synced into that systemuser table.

On the left side I’ve got a view of the environment’s user listing, as examined by the FF App Maker account that is both an environment maker as well as a premium licensed user. On the right side I have another browser session for the FF App User, who has received a link to our new Power App and clicked on it. Will the app open?

The answer is: eventually, yes. In my testing it actually took a couple of minutes for that “almost there…” spinner to keep rolling around. Finally, the Office licensed FF App User was able to click “allow” to grant permissions to the SharePoint connection used in the Canvas app. Once launched, the app was fully functional.

What can we learn from this? Obviously the concept of sharing Power Platform solution components like Canvas apps doesn’t rely solely on the Dataverse based security roles and record sharing concepts. The FF App User account didn’t become a user entry within the underlying database. So, it seems like the app security and sharing mechanism that would be used in an environment without a database is also present when a Dataverse instance exist.

As a summary: having a database provisioned for the Power Platform environment doesn’t have an impact on the app user license requirements.

Editing a Canvas app

Let’s continue our experiment further and see if the Office licensed FF App User account could also modify the Canvas app within a Dataverse enabled Power Platform environment. We’ll add this user as the co-owner of the app. Now when we access the Power Apps Maker portal as the user, we see an interesting result:

The app is listed and available for editing, as usual. However, we see a banner text warning us that “the user is not a member of the organization”. Indeed, this very is true, since when we created this new Power Platform environment we also assigned an Azure AD security group to it. FF App User is not a member of it, only the original FF App Maker account is listed here:

And yet this unlisted user account can see the environment in their Power Apps Maker portal, in the environment picker. What’s the lesson here? Even though it’s a best practice to assign a security group to every environment you create, it doesn’t technically block the user from accessing it. Presumably it acts more as a filter of what environments are visible if no other permissions have been granted.

Creating a Canvas app

Now that we’ve gotten this far with our Office licensed FF App User account, let’s keep knocking on doors to see where we can go from here. In the Maker portal, if we try to create a brand new app, we’re greeted with the message “it looks like you don’t have permissions to create apps in this environment”.

Fair enough. We’re just a user that happens to also be co-owner of an existing Canvas app within the Dataverse enabled Power Platform environment. Let’s go and add this account into the security group associated with the environment:

Upon testing the new app creation path again, the error message now tells that “the uses with id 11223344 has not been assigned any roles”. So, now we are finally operating within the Dataverse driven security model, meaning a security role should be assigned to the user account. Looking at the Users menu in Power Platform Admin Center, we can see that FF App User is now listed in the systemuser table, which measn we can grant the account a System Customizer security role:

How about Model-driven apps?

Up until this point in the article, everything has been performed within the rights granted by an Office 365 license. We’ve used a Canvas app that is technically stored within a solution (which lives inside Dataverse) but there have been no premium connectors or features used, as we’ve only accessed SharePoint data.

The fact that we’ve gotten this far without a premium license makes you wonder what else is technically possible. We now have the FF App User account as a row in the Users table of a Dataverse database, equipped with a System Customizer role that allows you to do quite a lot within the environment.

In the Power Platform Admin Center’s list of users, we can use the “run diagnostics” feature and check what the platform thinks about our user account. Everything comes back green, including the statement “this user has an active license or the environment has per app plans”:

There are no Power Apps per app plans assigned to this environment. We only have Office 365 E3 and Microsoft Power Automate Free listed under the “My account – Subscriptions” menu inside Office.

Yet we are now able to create a new Model-driven app in this environment:

Not only can we do Maker level things. We can also run a Model-driven app and use it for entering a new row into the Account table of this environment’s Dataverse database:

All of this is technically possible, thanks to the sequence of activities we’ve performed during this post. Yet it’s not something that we are commercially allowed to do with just an Office 365 license, since premium features like Model-driven apps and the full Microsoft Dataverse are not included. Not even Microsoft 365 E5 includes Power Platform features, you have to acquire these rights via a separate license.

Conclusions

Since the Dataverse data platform features are so deeply integrated with Power Apps today, it’s not easy to know in advance how the licensing enforcement layer affects the usage of features that are seeded within Office 365 (and Dynamics 365) licenses. Testing the above scenarios gave us confidence that just by enabling a database for your Power Platform environment you are not accidentally blocking scenarios for these seeded licenses.

Examining the platform’s behavior in the sharing and ownership scenarios also showed us how it is possible to “hack the system”. It’s an important reminder of the fact that just because a feature within the Microsoft cloud is technically available to you, this doesn’t guarantee that you have the right to use it.

As licensing plays such a central role in managing Microsoft’s low-code platform, we have also inlcude a dedicated licensing and capacity management workshop in our Power Platform Governance Starter Kit offering. While it may not be a similar technical topic like DLP policy configuration, for example, in practice it seems to be the area in Power Platform administration that sparks the most questions and discussion.

Want to get started with Power Platform governance?

We have created the Power Platform Governance Starter Kit product to help you kickstart you low-code application platform journey with confidence. Tools, reports, analysis and guidance from the Forward Forever team of experts.

Read more