There are a couple questions I get/issues I see quite often around setting up security in the D365FO user interface so I figured I would make a post around things to watch out for.
Security is still hierarchy based, and needs to be created in that way
One of the things I’ve seen done quite often is a user trying to set up security where they assign just the access type to an object that a security layer should have (so assigning just Create like in the scenario below).
If this is done, when the user tries to use this access later on they will get a permission error.
The reason for this is that the user only has Create permission but not Read and Update permissions which means they cannot open the form. But if we look to see if this role truly does have Create permission to the object we can test that it does.
So if a user were to be assigned this and ran some process to create a Customer, they would have the necessary permission to do that.
The correct way to assign security is to make sure it is hierarchy based, like below.
Where the role/privilege is assigned the lower level access types as well. This is automatically done for you if you set up security from the AOT.
One other thing to keep in mind is that for the Deny access level, the hierarchy structure of access types still exist but it is reversed from the Grant access level. Where as the Grant access types hierarchy from weakest to strongest are:
Read -> Update -> Create -> Delete
The Deny access types from weakest to strongest are:
Delete -> Create -> Update -> Read
So you would want to set up security like this:
When modify access to the same object in both the AOT and User Interface
In the past I’ve written about how you should pick where you are going to modify security and stick with it, either through the AOT or user interface. If you start modifying security in both areas and happen to make changes to the same object some very strange outcomes can occur. For example:
Scenario 1: Set up privilege in AOT with Read access to object, then set to Update in user interface and Publish the change
In the AOT this object appears to have Read access.
In the user interface the effective access displays this object has Update access.
Scenario 2a: Set up privilege in AOT with Update access to object, then set Read in the user interface and Publish changes
In the AOT this object appears to have Update access.
In the user interface the effective access shows this object has Read access.
Scenario 2b: Now if we go back to the AOT and set the object access to Create, what will the effective access be?
This actually surprised me, as I expected it to still be Read access but instead I found the effective access set to Create.
So now the question has to be asked, is the effective access being determined by the last published/synced security or is there some other process in play? To answer that I did two more scenarios.
There are a lot of steps with these next two scenarios but the idea here is that we are checking to see if security is set up in the AOT and then modified it in the user interface are we able to override that by again making changes in the AOT again?
Scenario 3:
- Set up privilege in the AOT with object access at Create level
- Go to user interface and set object access to Update level and publish
- Go back to AOT and set object access to Read level and do a database sync
After the user interface change the security is set to Update but after the database sync after the AOT security change the object access is Read.
Scenario 4:
- Set up privilege in the AOT with object access at Create level,
- Go to user interface and set object access to Read level and publish
- Then go back to the AOT and do another database sync without changing the access level (still set as Create)
If we go and look now, the effective access is still set as Read
- But now if I go into the AOT and set the object access to Read and do a database sync and then set object access in the AOT to Create level and do a database sync
The effective access to the object is now Create.
So after the initial change in the user interface we have Read access to the object just like we would expect.
After the first database sync we still have Read access to the object, but after we do the second database sync, we now again have Create permission to the object.
Modifying objects with AOT and User Interface Conclusion
After some exhausted testing, it appears that effective security is set by the process that last publishes/syncs security for that object as long as the security for that object has changed within that layer (either AOT or user interface). This can cause issues especially on the AOT side as the security settings will not reflect the changes being made in the user interface, so you can be syncing security and having it have no effect on the effective access. The only way to truly see what access an object has is to look at the effective access reports via the View Permission button in the user interface, or by going to the AOT and running the large View Related Object and License for All Roles report. It can also be confusing if a user is making changes in the user interface and someone else comes along and makes a change in the AOT (or vice versa) it will appear that security changes are happening spontaneously. The only way to see these changes is to look at the Audit Trail of the affected security layers.
Conclusion
These are just two scenarios that I have seen happen when using the user interface to set up security, hopefully knowing about these scenarios will help you avoid them in your own security setup.