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.
Hello, thank you for this explanatory use case.
I have a concept nonetheless that I don’t grasp at all: what would be the difference in adjusting the scope (from organizational to user) for the “Create” privilege? I am really eager to understand, because from what I guess, having the “Create” privilege on a table in a Security Role will grant the possibility to create new records in that table, whatever the granular level set (i.e., Organisation or User).
Thank you for your blog post again.
Hi Matthieu, thanks for the feedback.
The concept of User privileges on Create can be tricky to understand, as it’s more of an invisible concept. It still often sends me in circles.
With User-level Create privileges, the user can create records that they own themselves. This logically associates the record to the user.
With BU-level Create privileges, the user can create records within the scope of their BU. However, the user still owns that record. This logically associates the record to the BU. And so on for Org-level privileges.
The fine line here is in the context of where records can be created. Although the record is technically created within the context of a BU, visibility and access to that record by other users in the BU are dependent on their BU-level Read privileges and other possible RBAC layers.
For example, if you’re creating notes for yourself in an app, there’s no need to have BU context for that note record. If your supervisor needs to see that note, they’ll have a BU read privilege or apply a hierarchy model.
If you were creating a support ticket for a customer, ideally you’d create this ticket in the context of your support BU, as this allows the ticket to be associated with the BU, whilst still being owned by you.
Hope this helps a bit.
Hi Nati, thank you a lot for your detailed answer.
It helped me to read again the article with your precisions in mind. I think now I understand more the Security concepts complexity of Dataverse thanks to this “Create” privilege which acts kind of as a mind bender!
Now I need to try stuff in my dev tenant — some concepts are still unclear like, why the District Manager will create purchase orders in the context of his BU instead of his own context (User)? Because if I understand well, even if the purchase order is created in his own context (User), the sales person who is also in the same BU as the manager will be able to read the purchase order placed (because the sales man has read privileges set to BU level).
Or maybe being able to create a record in the scope of a BU lets someone create records and selecting which child BU is the owner.
Anyway many thanks for all your articles as they are nice cases to exercise these concepts. I think from this point I need to create different Security configurations to try and test to better understand.