I’ve had a few questions recently on various projects around the Master Data Services Model Object permissions. At a simple level they can be quite easy to master, but can get more complex as you try and combine the different permissions to create your desired security setup.
This guide assumes that you’ve set the Functional Area Permissions and given the user or group access to the Explorer functional area. The tables below show the different permissions that can be applied to each object within a model:
Model Permissions
This example shows the MS sample Customer model, which I’ve named as Customer Sample.
Permission |
Action |
Result |
Update |
The user will be a Model Administrator, meaning that they can add/delete/modify entities and access all data within each entity in the model. If they also have access to the System Administration functional area, then they will be able to actually add/edit/delete entities and other model objects. |
|
Read Only |
The user will be able to read the data within each entity in the entire model. |
|
Deny |
The user will not be able see the model. |
Entity Permissions
This example shows the entities that are contained within the same Customer Sample model.
Permission |
Action |
Result |
Update |
You can add/modify and delete members within the entity, in this case “Big Area”. |
|
Read Only |
You can read all members within the entity. |
|
Deny + Read Only on Model |
This is where it starts to get interesting. By having Read Only on a Model it means that you will have access to all entities. But by setting Deny on a specific entity, the user will now not see that entity in the drop down list. |
|
Update + Read Only on Model |
This will result in Read Only for all entities, but the user will be able to add, edit and delete members within the Big Area entity. |
Member Type Permissions
Depending on the entity, you could have both “Leaf” Member Type or Consolidated Member Type permissions (see here for the difference between the two). This table covers Leaf Members:
Permission |
Action |
Result |
Read Only |
Only choosing Read Only at the “Member Type” level will cause the same result as choosing Read Only on the entity. Therefore you will be able to read all members in the entity. |
|
Update |
You can add/modify and delete members within the entity, in this case “Big Area”. |
|
Deny |
The user will not be able see or access the entity. |
As you can see, if you only have Leaf Members within the entity, then the permissions are the same as if you are setting them at the entity level.
Attribute Permissions
Permission |
Action |
Result |
Read Only |
With just Read Only on one attribute, this will actually result in the user being able to view the whole of the Area entity, even though the Read Only permission has been set on one attribute. |
|
Update |
The user will be able to view the whole entity, but will only be able to modify the Big Area attribute on existing members. |
|
Deny |
The user will not be able to see anything, as Deny on just an attribute is not enough to give the user access to the entity. See the next row for how to correct this. |
|
Deny + Read Only on Entity |
The user will be able to view the Area entity, but the Big Area attribute will not be visible. |
|
Update + Read Only on Entity |
The user will be able to view the entity, but will only be able to update the Big Area attribute. |
|
Read Only + Update on Entity |
The user will be able view, add and edit members, but will not be able to specify a value for the Read Only attribute. The user can, however, delete members. |
The last three examples really highlight how combining MDS permissions can be powerful. Lets look at these in more detail:
Deny on Attribute + Read Only on Entity
Setting Deny on the Big Area attribute, but Read Only on the entity will result in the user seeing the following:
The “Big Area” attribute is completely missing from the MDS Explorer grid.
Update on Attribute and Read Only on Entity
On the other hand, setting Update on the Big Area attribute and Read Only on the Area entity will result in the user seeing the following when editing a member in the Area entity:
The two highlighted attributes (Name and Code) are both Read Only as we set the entity to be Read Only. The user can edit the Big Area attribute for each member, as we gave the user Update permission on that attribute.
Read Only on Attribute and Update on Entity
Finally, in the last example we have Read Only on the Big Area Attribute, but Update on the Area Entity. This means the user cannot specify a value for the Big Area attribute:
So there we have it! Hopefully this post will be useful – as you can see the MDS Object Model permissions can be very granular and should be able to cover most of the scenarios that you need.
Using Copilot Studio to Develop a HR Policy Bot
The next addition to Microsoft’s generative AI and large language model tools is Microsoft Copilot
Apr
Pretty Power BI – Adding GIFs
Good UX design is critical in enabling stakeholders to maximise the key insight that they
Apr
Pareto Charts in Power BI and the DAX behind them
The Pareto principle, commonly referred to as the 80/20 rule, is a concept of prioritisation.
Apr
Databricks: Cluster Configuration
Databricks, a cloud-based platform for data engineering, offers several tools that can be used to
Apr
AI Assistance in Microsoft Fabric
The exponential growth of Large Language Models (LLMs) couples with Microsoft’s close partnership with OpenAI
Apr
10 reasons why it’s worth the effort to understand the value of your data
“If leaders really want to create a data driven culture, the journey starts with them!
Apr
Content Safety in Azure AI Studio
Azure AI Content Safety is a solution designed to identify harmful content, whether generated by
Apr
Model Benchmarks in Azure AI Studio
In the constantly changing field of artificial intelligence (AI) and machine learning (ML), choosing the
Apr