Column Level Security in Dataverse

Background – Security in Dataverse

If you’ve worked on any Dataverse projects before, there’s a likelihood that you’ll have at least a basic understanding of security concepts around Dataverse. Dataverse works on role base security where users are assigned a role to group a number of access rights those different roles grant them.

Other security features of Dataverse include business units which create security boundaries within Dataverse and only allow the data for specific business departments or units to be seen by those groups. We can further have child business units within those business units for example where we might have a ‘Finance & Operations’ department where ‘Finance’ and ‘Business Operations’ are two child business units under our ‘Finance and Operations’ business unit.

We can go further to look at how Dataverse is controlled by two types of record ownership including organisation owned, or user or team owner, which is a preference determined at the time of table/entity creation. We can look at Teams which are owned by business units and have two types being owning teams where that team can own records, giving any team member direct record access here, and the alternative being access teams which are more relevant to the sharing of records.

We can further work down to record-level security implementation in Dataverse where the combination of a users security roles, business unit, teams and shared records determine the records a user will have access to and the actions they can take against those records.

Finally, to get really granular, we can even work down to the point of column/field-level security in Microsoft Dataverse. In this post, we’re going to look at the reasons we might want to implement field level security and how we can do this within Dataverse.

Why?

So, before we think about implementing a cool or ‘fun’ feature in our solution, we really need to think of the reason behind what we’re doing and whether it is going to solve the business requirement we’re aiming for. There’s many reasons you might want to implement column level security in Dataverse.

Let’s take a leisure centre swim scheme as an example. Being a swim teacher… I know how it works a bit! In many swim schemes, you’ll find swimming teachers don’t have any access to contact details or parents for the children they teach to swim. However, the swim scheme manager will have access to these to be able to control communication with those parents.

Here we have a scenario where it is ideal to centralise data in one place to prevent duplication and admin time, so one database needs to be used, and potentially the same records need to be seen, such as the swimmer and who their parent is. However our swimming teachers need to be able to only see limited information on those teachers. This is an example of where we would implement column level security to hide the fields that teachers shouldn’t see whilst providing a higher level of access to the swimming administrator who can see those fields.

How?

Now let’s get to the main bit… what you’re really here for! How do we actually implement column level security in Dataverse?

First we need to ‘tables’ in Power Apps, go to the dataverse table we want to use, select the table and then find the columns we want to turn column level security for on, edit them and check the option for ‘enable column security’.

Starting to configure our column security

Now we need to go to our Advanced Settings in Power Apps/Dynamics 365. You can do this by selecting the options icon in the navigation bar of make.powerapps.com or a model driven app, then click ‘advanced settings’.

Then, go to Security under Settings so that we can do some configuration around the columns we have turned column level security on for.

From here we want to go to our ‘Field Security Profiles’ and we want to select ‘new’ within that screen to create a new ‘Field Security Profile’

This is how we can start to configure the teams and users (the group of people / or the person) we’re going to assign to a set of field permissions.

In this window, we want to give our field security profile a name and then save it, so that we can start configuring it.

Once we’ve done that, we can go to either teams or users to add some people to this profile. Ideally, where you have teams with pre-defined requirements as to the data they need to access you would adopt this approach of assigning members into the profile. Adding users to this part of Dataverse when it comes to security could become slightly tedious.

Once we’ve added our members, we will tell the field security profile which field permissions we’re going to assign those users.

If you go to field permissions you will notice all of the fields appear where you have enabled column security in your Dataverse table columns.

If we click into each of these fields, we can tell the profile which permissions we want to allow the members of the profile to have against which columns.

Simply select the column you want to change permissions for, and adjust whether users should be able to read, update, or enter new data into those columns.

Now, when using those fields in your applications and Dataverse, these set of permissions will apply to the users within the same field security profile.

I hope this post helped you with getting started with column level security in Dataverse. Remember, if you’re trying to implement this on an organisation level, and not just for your own testing… teams are the way to go!

If you liked this post you can subscribe to get the latest below.

Subscribe

Sign up with your email address to receive news and updates.

Thank you for subscribing!