Teams Real Simple with Pictures: Setting Table Permissions for Dataverse for Teams Apps such as Bulletins or Employee Ideas

This blog is part of a series on Teams. For more articles, check back often

Written: 28/03/2021 | Updated: N/A

Last month I wrote a bit about the new Power Apps Templates in Teams – Bulletins and Employee Ideas, and last week I discussed Applying DLP policies to the environments these apps are housed in. Now It feels pretty natural to continue this conversation about data and discuss Table Permissions within the apps themselves. This is because it’s these permissions which determine how users inside and outside the team – and guests – can work with the apps and the data that they contain. Firstly, it’s important from a usability perspective that we can granulate access. Think of the following scenario – one team member needs full access over one app in the environment because they are managing it whereas that same user may only need read access over another because they don’t need to touch any data within it or add any data to it. You may also want team members to be able to modify data with a specific part of the app – for example links in Bulletins, and not in others. This is all possible with table permissions. Secondly, it’s also important from a security and compliance perspective. We want the users we need using the app in the way we specifically need them to use it. Circling back to the DLP conversation last week whilst we want to trust that others will handle the apps and the data within them in the right way, having carte blanche in terms of permissions, or even having permissions for certain users, or guests, at all opens things up to all sorts of risks including insider threats. Like DLP, this is certainly something we want to think about when we deploy, or when we are sharing it outside the Team.

This blog will cover

  • Modifying Table Permissions for those inside the Team and Guests
  • Modifying Table Permissions for a specific individual within Members
  • Modifying Table Permissions for a specific feature within an app
  • Table Permissions for those outside the Team in a broad distribution scenario

Prior to reading this it’s important to understand that there are 4 permissions sets currently available for Dataverse for Teams Apps

  • Full access – Allows end users to see and edit all records in the table
  • Collaborate – Allows end users to see all records, but they can only edit their own records
  • Reference – Provides a read-only view of data for end users.
  • Private ­- Allows end users to only view and edit their own data

There is also

  • None – Can’t access records at all

It is not currently possible to modify them, nor is it possible to create custom permissions sets. Also to note, only Team Owners can update table permissions. Team Members (even if they created the table or installed the app) cannot update table permissions


  • Full control on the app (usually through deploying the app within the Team)
  • Teams/Power Apps/Power Automate Licence to test (Usually within Microsoft 365 Subscription


Let’s start out. By default

  • The Owners and Members have Full access by default
  • Owners of team have admin rights – so you really cannot downgrade their permission level from Full
  • Guests have Private permissions

Let’s imagine a fictional scenario. we want to change permissions for Employee Ideas so that Team Members have Reference Permissions and Guests have None

1.) In Teams select Power Apps from the app rail

2.) Select Build

3.) Select The Environment, then Installed Apps and on the app (s) you want to modify the table permissions select See All at the bottom of the app card

4.) Select Tables from the left menu

5.) You now will see a number of tables. Select More Options (…) on one of the tables, then select Manage Permissions

6.) You can now change the permissions for both Members and Guests to the level you want them to have. Here the fictional requirement is for Team Members to have reference (read-only) access and Guests to have none. Once done select Save

7.) Rinse and repeat for all of the tables

8.) The outcome of this is that all members of the team will not be able to submit ideas, or vote up on them. They will only be able to see what others have added. An error will show that the team member does not have write permissions. For the guest, no data will show at all as they do not have any permissions – neither write nor view


Scenario 2 follows the above. We have set table permissions for members and guests. However, what if you want to have a single Team member or a few team members which need to have different table permissions. For example, you want them to co-manage the app with you and have full access. As shown above in the screenshot you can’t set exceptions with Table permissions so how do you get around this? In this case you would create a security group for the specific individual and set the table permissions on the security group. Let’s show you how to do that

1.) In the Microsoft 365 Admin Centre create a Security Group with group members being members of the Team whose permissions need to be different than others

2.) Return to Power Apps in Microsoft Teams and within the Build Tab select the Environment and then Share with Colleagues

3.) Add the security group created, share the apps required via the sliders and select Save

4.) Now modify the table permissions as required for the security group which appears under colleagues with access and select Save

5.) Rinse and repeat for all tables

This image has an empty alt attribute; its file name is image-147.png

6.) The end result is that regular members of the Team will not be able to write to the app (since they have reference permissions)

7.) Whereas Team members in the security group can do this with the elevated table permissions

Is this a good idea? It would work in some app scenarios but not in others. Why? Because when you share the app with colleagues you only have a single slot for a single security group and typically, you would use that to share the app outside of the Team with others in the wider organisation as a broad distribution scenario. However, if the app wasn’t being shared outside the team this would be a perfectly valid way to segregate multiple app owners with full access and regular members of the Team and guests which would have contribute, reference or private permissions


Ok scenario 3 concerns permissions for a specific feature in an app. This is all dependent on setting the permissions for the corresponding tables. Bulletins is a great example here. Let’s say you are ok with letting everyone else in the Team publish new bulletins and FAQ’s and even amend their categories, but let’s say you don’t want them adding new links or contacts or changing the links/contacts categories. How do we do this?

1.) In Tables within the apps environment you would only amend permissions on the relevant tables for the feature. In this fictional example, three tables to amend within the Bulletins app are Bulletin Contact, Bulletin Link and Bulletin Link Category

2.) You would change all three of these for Members to reference permissions

The end result is that Team Members can add, change and delete bulletins and FAQ’s but only read contacts and links


As has been written previously with Bulletins and Employee Ideas, you can share the apps outside the organisation using a security group. However, it’s important to add here for completeness that when doing so, permissions are not granted automatically to the security group when the app is shared; in other words, for the security group and colleagues outside of the team table permissions are None by default

So it’s a simple case of assigning the right permissions to the security group for users outside of the team in order for them to be able to use the app in the way you require. Don’t forget! Otherwise they will likely be chasing you saying that the app is not working!


Table Permissions are a good way to regulate and control access to the data within the apps installed with the Dataverse for Teams environment. It is another tool in the governance kitbag and together with DLP gives us options for securing our data: ones which are really necessary to think about before we even deploy our apps