A Tale of Privilege: Business Units and Security Roles

The Power Platform and its variety of specialised products offer a fortune of development capabilities. One thing that stands out a lot within Dataverse, making it more than just a cloud database, is the concept of Business Units and record ownership. But that’s just the start. By aligning Business Units with Security Roles, we can start to enhance a security model and can actually start building complex Role Based Access Control (RBAC) models.

Let’s jump straight into it.

The Breakdown

We’re all probably familiar with what Business Units are and how they work. To briefly summarise, Business Units are used to determine where data is stored in relation to specific data activities. For example: The company “Turtle Life” has various shop locations across the country, all using the same sales app built using the Power Platform. They all sell the same items; however, transactions per location are restricted per site, meaning that shop A should not know about Shop B’s sales. Head office, however, needs to see overall sales for all their branches.

In this scenario, we would create two child Business Units. The parent Business Unit already exists within the environment, and the two new Business Units would be called Shop A and Shop B. Slowly, our Business Unit model is starting to look something like this:

With this in mind, an admin can now start adding sales members to these various Business Units. If Steve Rogers works at Shop A, the admin will assign him to the Shop A Business Unit. Without diving too much into how Security Roles work at this moment, ultimately, Mr. Rogers should now only be able to see customers, sales, PO’s, and stock within his location. In this case, Shop A.

When Steve also transacts with sales in Shop A, that transaction now sits within the Shop A Business Unit. In the below image, we can see how a record transaction will now be assigned to a User, Organisation or Team:

In a scenario where the Sales table is organisation-owned, the transaction created by Steve will be assigned and therefore controlled by the default organisation.

In a case where the Sales table is user- or team-owned and Steve belongs to a team and has no roles assigned to him individually, the record created will be assigned to the Access Team and the Business Unit he is part of.

Lastly, in a scenario where the Sales table is also user- or team-owned and Steve has a role with create, read and write privileges to the Sales table, he and his assigned Business Unit will become the owner of the transaction.

So, if we make use of this exact concept for Shop B, we will have the same result; however, Shop A and Shop B would not have access to records that are not in their store. Our process is starting to look a little something like this:

The Principle of Least Privilege (PoLP)

What is PoLP? When it comes to developing solutions, especially if the solution will store sensitive data, best practice states to lock up access as much as you can and slowly release little bits as needed. We’re giving users minimum levels of privileges to ensure that they don’t stumble across data that should not be seen.

How does this apply to the Power Platform?

Security Roles

Well, we have already discussed Business Units and how Shop A and Shop B should not see each other’s data. Using Security Roles, we can start locking up this data.

Security Roles allow us to lock up data per table on a per-user, Business Unit and organisational level. When dealing with Security Roles, there are two types:

• Team privileges only – assigned to teams that contain users without direct assigned roles to create specific records.
• Direct User (Basic) access level and Team privileges: Assigned to a user, allowing various levels of access with privileges such as create, read, write, delete, and assign.

In our scenario above, we’ve segmented each store’s data into two different Business Units. As much as head office doesn’t want the stores to see each other’s data, there are cases where it would be beneficial. Let’s apply a real-life scenario here. You go to a store to buy a shirt, but luck has it, they don’t have your size in stock. The store being able to lookup stock levels at other locations would actually be very helpful, right? But if we have locked down our data to a per-site (Business Unit) level, how would Shop A see Shop B’s stock? And as a customer, you would also probably like to use your loyalty points you’ve earned from shopping at previous locations.

There are a few ways to solve this issue, but let’s talk about two simple ones. We can create a Security Role called Sales, and this role will grant assigned users various levels of access privileges to some tables.

Approach 1

If we were to create the Inventory table as an organisation-owned table, there would be no Business Unit bricking up access across the two shops. The inventory now belongs to the organisation, not the shop. However, this may not be the best approach, especially when dealing with incoming purchase orders, stock variances, etc. Shop A store should be responsible for its own stock.

Approach 2

Either the inventory manager as a user or an ownership team owns the records in the inventory table. The stock will be assigned to the Business Unit that the user or team is part of. In this case, Shop A. In order to share stock levels with other locations, all sales staff across the organisation can be assigned the Sales Security Role which grants them access to the inventory table on an organisational level. So despite Shop A being the record owner of its stock, Shop B will still be able to view Shop A’s stock when necessary. Additionally, we can grant this role User privileges to create and write to the Sales table, meaning that sales and transactions done by Steve belong to Steve and his assigned Business Unit. Steve, however, can view his colleagues’ sales but cannot edit them or take over a sale until his colleague assigns him that sales record.

Both approaches can be illustrated below:

You can also see from the above example that we have implemented the principle of least privilege. This ensures that users assigned to this Sales Security Role cannot create purchase orders but can only see PO’s raised from within their Business Unit. This gives us space to now create a new role called Purchasing that grants the purchasing team privileges to create new PO’s while still allowing salespeople to see when stock is arriving.

Back to Basics

I’m using this phrase a lot lately, but these basic concepts that we’re familiar with are the pillars that form complex security models in the long run. The example we’ve used in this post is relatively straightforward, but more complex cases where we start using record assignment, column security profiles, and even a hierarchy model will surface. Grasping the basics now will result in a rock-solid model that can be scaled, ensuring secured data.