Solutionise Security Roles the Right Way

Expanding on our Roles

In my previous post, I used an example of a sales guy called Steve who was assigned the Sales Security role and was therefore able to capture his sales, which allowed his fellow colleagues to see them. Granted, his fellow salesman could not edit his sales; they could only view them.

Let’s introduce a district manager as well as a second location. The district manager needs to be able to see all the team sales records, log sales himself, and also create purchase orders to buy more stock. The same access principles apply for the second location, but sales at each location need to be locked up per site and not accessible from another store. Only the district managers should be able to see another store’s sales. All other staff are only allowed to see each other’s stock levels.

We can start with the Sales Security role. If we look at the model below, we can see that any staff member assigned this role can view and create customers across any store location. They can also view all stock levels per site as well. When it comes to sales transactions, we have locked up sales records so that everyone in Steve’s location can view his sale, but only Steve can edit his sale if need be.

So, if Steve logged a new sale for today, no one but him could be able to see the sales record. It would look something like this:

All staff, no matter if you are part of the sales team or if you are the district manager, get assigned the Sales Security role, as anyone should be able to log a sale. This is why all members of Shop A can see Steve’s sale. However, because the Sales table is set to a read-only level Business Unit privilege, should Tony from Shop B want to see Steve’s sale within Shop A, the security role will block him from seeing that sale as well as anyone else that works at Shop B.

But because we want the district managers to be able to see all location sales as well as create purchase orders, we need to create a new security role and assign it to them. It will look a little like this:

Let’s not unpick why the Principle of Least Privilege was not used for these two roles. It’s late and I’m tired. But with this role assigned to the district managers for Shop A and Shop B, we have now granted additional data access on top of the Staff Security Role. With the above District Manager role, assigned users can now see sales across other shops to compare their sales figures and can also create purchase orders for their location.

Layering Security Roles

Using the Principle of Least Privilege sometimes takes a moment to get used to. When it comes to security roles, you can have one role granting read privileges to a table, but another role revoking read privileges to the same table. If both of these roles are assigned to a single user, there won’t be any conflict. The highest privilege takes preference, meaning that the role that gives the user read rights will supersede the revoking role.

Taking this into consideration, you can start to see how important PoLP really is. Your lowest access role should block nearly all unnecessary tables. As you start to build your roles as per access requirements, you only grant access to tables the role requires. This ensures that should there be an overlap with another role at some point, the assigned user is still seeing exactly what they’re supposed to see and not an ounce more.

Security Roles in Solutions

Similar to various other Power Platform objects, when you are building a solution, you can create security roles within a solution or even add existing roles to your solution. Ideally, if you are making use of an existing Power Platform security role, it is recommended that you copy the role and make adjustments to the new role to avoid unforeseen issues.

Anyway, back on topic. When creating a security role within a solution that the solution will also be dependent on, it is imperative that you do not assign the role to a child Business Unit within the environment. By default, when creating a new security role, the assigned Business Unit will be the environment’s default Business Unit. If you have created a couple more Business Units to assist with development and regression testing, just be extra cautious and don’t link objects to those Business Units.

In the example below, I created two security roles within a solution. The first was assigned to the default Business Unit, and was then added to my solution.

The second was assigned to a child Business Unit, but it did not get added to my solution.

When trying to add it again, the following error occurred: Subcomponent [object id] cannot be added to the solution because the root component Role is missing. This is because Power Platform will automatically cascade the security role to the various Business Units when set to default, but when set to a child Business Unit, it fails to do so. This can be validated by looking at the Security Roles table. For the first security role created, you can clearly see it has been cascaded per Business Unit, whereas for the second role, the cascading failed. So because the root Business Unit for the second security role is missing, it is unable to identify the root object as a default to add to the solution.

The role will work; however, if you continue developing your solution with this role, say assigning the role to a form within a custom entity, you may run into some issues when deploying. Personally, I’ve seen Power Platform be really nasty with roles and fail to import the solution based on the missing root subcomponent, i.e., the default Business Unit for the role, because the child Business Unit does not exist and the two cannot be linked across environments. I’ve also seen Power Platform become a bit logical, and sometimes it removes the display conditions from the form that is reliant on the role. It’s definitely nice that you get a successful import, but it stinks that you may lose out on the customisation you intended on brining over.

Too Much Going On

There is a lot to put on a page, both textually and visually. Sometimes I prefer laying out some basic diagrams to explain how a process works rather than writing out too much text. My problem is that I then tend to jabber on about nonsense, such as I am doing now.

Security Roles are an intricate part of Power Platform security, but they only make up a small part of the bigger picture. As we start to piece these basic concepts together, an image of what we’ve accomplished so far with just some simple concepts will start to emerge, and it will actually look really cool! Sit tight.