Dataverse for Teams governance, part 1: can we block it?

Microsoft wants to enable every Teams user to build business applications for their needs. It’s all part of the greater Microsoft Teams as a platform story where the data from various different systems and sources is brought into the context of the teamwork that happens in channels, chats and meetings.

Dataverse (formerly Common Data Service) is now offered as a tightly integrated part of Teams. The full version of Microsoft Dataverse can power large enterprise systems like Dynamics 365, whereas the lightweight Dataverse for Teams is aimed at citizen developer scenarios. Both of these will show up as environments in your tenant’s Power Platform Admin Center:

First the good news: Dataverse for Teams is “free”! It comes bundled with most of the Office 365 / Microsoft 365 licenses. However, it is not an unlimited resource. There is a maximum capacity of how many environments you can have in Dataverse for Teams across your tenant. While storage is capped at 2 GB per environment, the formula to count the available environments is: 5 + 1 per 20 eligible Microsoft 365 seats.

So, it’s something you need to be aware of and manage. By default, any team member can create a Dataverse for Teams environment. Just by testing the Power Apps for Teams app and creating a blank “Test123” app the user can burn the quota available in your tenant. How could we avoid or at least reduce the clutter from such environments?

There are different ways to approach this. In this Part 1 blog post I’ll examine the option that may initially come to mind for administrators in charge of Microsoft 365 services: restricting user rights. I’ll demonstrate the impact from these actions and lay the foundation for considering a more advanced governance approach that will be covered in Part 2.

Applying Teams app permission policies

Let’s play the role of an IT admin who wants to just eliminate the problems caused by all this new innovation pushed by Microsoft and chooses to block everything related to Power Platform tools. In the Microsoft Teams Admin Center we’ll create a custom app permission policy, then in the Microsoft apps section choose all things with “Power” and add them into the block list:

We’ll apply this policy for User A and let another User B roam free with the Global (org-wide) default policy. The following screenshots will compare the blocked vs. default experience for these two users.

Let’s first go and have a look at what the list of apps available in Teams is like for User A and User B. As expected, our policy has trimmed away all of the Microsoft apps listed in it. When User A searches for “power”, there are only third-party results:

Let’s look at the “built for [my company]” section in the apps list. Here the blocked User A is able to access all of the apps listed in “built by your org”. These have been directly imported into Teams and have therefore gone through a review by an admin with the required privileges. The second list, “built by your colleagues”, is only visible to User B. These are apps that have been built with Power Apps and shared from one user to another, without any admin intervention needed.

Just because User A has been blocked from running Power Apps for Teams, this doesn’t block the installation of a Power Apps based business application into Teams. Let’s try adding one of the “built by your org” apps into the Teams left rail. The experience is identical with User A and User B:

Power Apps may of course be found in many of the existing Teams channels as a tab. If these are “standalone apps”, meaning built outside of Teams in the full Power Apps Maker experience, then the permission policy will make these apps invisible to User A. The tab for such an app will simply not render in the UI.

If the Power App has been built within Teams, meaning it exists in a Power Platform environment that is natively linked to a specific team, the story is different. Let’s try an app that is built on Dataverse for Teams, like the Milestones sample app from Microsoft. There is no difference between what the blocked User A and default User B see upon accessing a tab with this app:

So, if running apps isn’t categorically blocked, then what specifically does the Teams app permission policy block User A from doing? The answer is: it stops the user from accessing the app maker experience available in the Power Apps for Teams app. Since the blocked users can’t add this app into the Teams sidebar, they won’t be able to browse any of the components found within the Dataverse for Teams environment – or create anything new. Only the published apps can be consumed, but regardless of the User A’s team membership role, he/she won’t get to the “Build” tab that User B sees:

It doesn’t even matter if the blocked user would attempt to “escape” the Microsoft Teams client and open up one of the existing Power Apps in a browser tab. Any app that’s built within Dataverse for Teams is only supported to run within Teams. Besides, an app user in general won’t have access to any of the app maker capabilities, like creating tables, apps and other solution components for Power Apps.

Adding apps that are built on Dataverse for Teams

It might sound like our User A has been blocked from consuming any Dataverse environment capacity now. That’s not entirely true, though.

Let’s say our user creates a new team called “Secret Project 404” for working on something highly confidential together with a small group of people within the organization. To support this work process, he/she then browses the list of available apps within Microsoft Teams app store and comes across an app called “Issue reporting” from Microsoft:

“This is just what I need! I’ll add this into my team’s General channel right away.”

What happens next is the provisioning process of a new Dataverse for Teams environment! This is all automated and happens behind the scenes when the first app requiring these features is added into a team.

Furthermore, even if your tenant would be out of environments capacity, that’s not going to stop this process. As of today, there doesn’t appear to be technical enforcement on the organization limits for Dataverse for Teams. That doesn’t mean it will always be like this, but right now you can easily step over the quota allowed by the terms of service, as we see here:

Why did these actions of User A who had been blocked from using most of Power Apps functionality still result in a new Power App and a new environment being created?

If we examine the Issue reporting app more closely, we see that it’s “Built with Microsoft Power Platform. Ready for you to extend.” The idea behind having these apps built on Dataverse for Teams to begin with is of course that the business users could modify the data model, user interface and processes without necessarily having to consult the IT or professional software developers.

Except that we’ve just blocked the extension path from User A via our Teams app permissions policy. Clicking on “Customize using Power Apps” will give the user an error message: “app not found – the app may not exist, or your organization may have disallowed you from using it.” So, what we’re left with is an uncustomized app consuming resources within the team.

Could we block these sample apps then? Technically, yes. Should you pursue the strategy of adding a growing number of Dataverse for Teams based business apps into your block list? Not unless you have a really good reason for stopping Microsoft Teams users from leveraging Microsoft Teams to get their jobs done via modern low-code apps.

Conclusions

As we’ve seen from this experiment, blocking the use of Power Platform tools isn’t necessarily the optimal approach to establishing healthy governance practices for Dataverse for Teams. It also goes completely against how Microsoft is designing these tools to work in the first place. Using “only Teams” or “only SharePoint” doesn’t make all that much sense if you read how Jeff Teper, Microsoft CVP for Teams & SharePoint, sees the role of Teams as a platform for innovation:

“Here’s how I think about the building blocks coming together: SharePoint and Dataverse can provide the storage. Power Apps enables the rapid development and deployment of tailored applications. And Teams serves as the front-end of it all, bringing the Microsoft 365 collaboration and communications experience into a single hub.”

In Part 2 we’ll explore a different approach. We’ll actually be leveraging the platform itself to offer us governance tools for what’s happening with Dataverse based apps within Teams.

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