On its face, D365 Finance doesn’t seem to add major functionality to the security features, maybe a button or two. However, that minor change to the UI may actually be a game-changer. 

The security model in AX 2012 helps organizations comply with regulations like Sarbanes-Oxley (SOX) regarding segregation of duties, but the feature set has notable limitations. Access can be granted on an incremental scale, ranging from read-only to full control, with each access level building on the prior. The highest level of access granted to a user from any permission will be the effective access a user is able to achieve in the system.  

The access levels within Dynamics AX 2012, from least to greatest: 

• No access – the user is not able to view the entry point but can gain the access from another security role that contains the access. 
• Read – the user can view the entry point but cannot make changes to any records. 
• Update – the user can view the entry point, make updates to existing records, but cannot add new records. 
• Create – the user can view the entry point, make updates to existing records, and create new records. 

• Correct – the user can view the entry point, make updates to existing records, and create new records and correct date-effective record without creating new records. 
• Delete – the user has full control of the entry point. This includes viewing, updating, creating, correcting, and deleting.  

Let’s look at an example. If I want to create security where a user would only be able to only create and delete a vendor record, I need to look at the highest amount of access the user would need and grant that access. For this example, the security we are creating would need Delete access. Because the access levels in Dynamics AX 2012 is incremental, we would be giving access that has more than is needed (or even wanted) but to allow for the security privilege to delete the record, they inherit all the lower levels of access in the process. This does allow for a simpler, more streamlined process of creating custom security. This sounds efficient, but there are certainly cases and conditions where this model is too rigid and linear. 

In the Dynamics 365 Finance security model, the access levels are more granular and easier to understand. Now you can grant access based on what the user should be able to do, no more, no less, minimizing the risk of undesirable amounts of access being granted to the users.  

The D365 Finance model is superior in comparison to Dynamics AX 2012. I like to think of it in terms of a new car and the changes we all take for granted now. Growing up, my mom probably drove around in a 1990-something sedan with a cassette tape player and radio. If mom wanted to listen to talk radio, we all listened to talk radio. What one of us listened to, we all listened to. But now, as a mom, I have a 2020-something SUV with dual-zone media. I can listen to my music in the front, play a movie with audio in the back, or even send the audio to headphones so I don’t have to hear yet another hour of cartoons (I’m pretty sure I’ve already seen that episode about 50 times.)  

D365 Finance security is like that new SUV, with “dual” and dynamic ways of taking different access levels and allowing them to be like “building blocks” to create exactly the security you desire.  

The access levels within D365 Finance follow these “building block” steps: 

• Read – the user can view the entry point but cannot make changes to any records. 
• Update – the user can update existing records. The user cannot create new records or delete the record. 

• Create – The user can create new records. The user cannot update existing records past the creation screen and cannot delete records. 
• Delete – The user can delete records. The user cannot update existing records or create new records. 

Like Dynamics AX 2012, the highest access level granted to an individual user from a combination of privileges, duties, and roles will determine what the user can achieve in the system. D365 Finance adds an enhanced control with the introduction of three properties within each access level: 

• Unset – The user is neither given nor denied access to the entry point. If another permission is granted to the user that grants the access, the user will be able to access the entry point.  
• Grant – The user is given access to the entry point with the respective level of access. 
• Deny – The user is denied access to the specific permission (read, update, create, delete) regardless of any other security assigned to them.  

Let’s go back to our example about only wanting to a user to be able to create and delete a vendor record, but not maintain: 

With D365 Finance, you would grant the security privilege the access to “Read” “Create” and “Delete”. In this example, the user could see all vendors, create a new vendor, and Delete existing vendors, but would not be able to modify any vendor records past the vendor creation and initial saving of a new vendor record. There is certainly an advantage to being able to split out the creation and maintenance of existing records, especially in the instance of highly regulated companies to comply with rules and regulations for certain areas of the ERP system. 

D365 Finance has a fully customizable security design. Whether your project calls for minor tweaks to copies of out-of-the-box artifacts or a wholesale custom security suite, you can right-size your security solution and fine-tune the access that users have. 

Oftentimes role-based security is an afterthought in ERP projects, but that approach can come back to bite a project in the end. Include security access from the outset to help avoid unauthorized changes and segregation of duty conflicts.  

Stay tuned for more thoughts and updates on security in Microsoft Dynamics and the Power Platform!