D365FO Security Setup: Configuration or Code?

Photo designed by FreePik

When developing or modifying Dynamics 365 for Finance and Operations security, a question I get quite often is ‘Where should I make my security changes? Is it better to make changes via the Security Configuration page within D365FO or should I make security changes via Application Explorer / code?’

I’ve written about the differences in these approaches in the past (Setting up Security from the User Interface and Setting up Security from the AOT) but which option is better for your organization? Let’s look at the pros and cons of each, and why you might want to choose one approach over the other.

Using Security Configuration Pros and Cons

• Shorter time to develop and implement – using the Security Configuration option allows for quicker turn around times to develop and deploy security changes as you do not have to wait for a developer to make these changes.
• Security creation and modification can be done by non-developers – as a follow up to the previous point, because developers are not needed to make security changes the number of individuals who can make these changes will be larger.
• Harder to maintain security changes across environments – when developing security via configuration, the actual security elements are stored as data. This makes it more difficult to ‘check in’ these types of changes to source control. You can rely on the Export/Import functionality within the Security Configuration area but this exports and imports all changes (which may not be the desired outcome). In these cases, the Security Migration tool from Fastpath or the Security Migration tool can help.
• Allows for complex deny scenarios – if you want to deny only certain access types for an object (ex: Deny just the Delete permission but grant Read access to an object) this can only be done via Security Configuration. For example, the below setup where we are denying access to the Update, Create, and Delete permissions to a menu item while allowing Read access is not a scenario that can be (at least easily) replicated via code:

Using Application Explorer / Code Pros and Cons

• Developing and implementing security via code normally takes longer than via configuration – this is because normally development processes either need to go to a separate team (sometimes offshore) as well as requiring a more thorough testing and deployment process.
• Security development must be done by developers – the changes to security are performed by a user that has access to a development environment of D365FO.
• Because these security elements are created in code, the maintenance of these are more straightforward – these security changes can be checked into source control and any changes to them can be tracked and documented. For organizations that require compliant security or have audit requirements this can help with the overall security maintenance process.

Other Questions / Thoughts

• Is it better to make your security changes via configuration or via code?

This is the million dollar question, there is no ‘better’ option by itself but there absolutely may be a better option for your organization based on the pros / cons laid out above. Each organization can decide which is best for them. Both options can work as long as the organization has a process in place to effectively make their security changes in a compliant fashion.

• Can I create security in Security Configuration and move it to the Application Explorer / Code?

Yes you can, however there is no native functionality within D365FO to perform this. The reason for this is that the actual security element data and format is the same whether you create your security from configuration or code.

As an example, if I create a role with the following access to the VendTableListPage object:

When I export the security changes via Security Configuration I get one XML file that contains all role, duty, and privilege changes:

If I replicate the same role creation via code, the role and privilege XML files created contain the exact same XML data and structure just broken into multiple files:

Since the data in both of these files is the same you can absolutely move security elements between configuration and code as long as the resulting XML file is valid and in the correct format. If you would like an automated process for this process, there are tools to help with this in the next section.

• Can I use a combination of both Security Configuration and the Application Explorer / code to develop and maintain my security?

Yes you can! The most important piece here is that you have a process defined for your organization in place on the scenarios of when to use Security Configuration and when to use the Application Explorer / code for security design tasks.

• How do I ensure that my security changes are maintained and deployed correctly?

This is a crucial step in the security design process, if proper maintenance and source control are not followed then all of the work done to correctly create compliant security can be easily undone. From a best practice standpoint, it is always best to ‘treat your security as code’ in that the same steps you perform to develop, test, and deploy custom code in your environment should be performed for security as well.

More information on this topic can be found here: Best Practice for Moving D365FO Security Between Environments

Tools to Help

Security Comparison Between D365FO Environments – this is a free tool offered as part of the D365FO Admin Toolkit which allows you to compare security from multiple D365FO instances and exports any differences to an Excel file. More information on this can be found here: https://alexdmeyer.com/2024/07/16/comparing-security-between-d365fo-versions/

Fastpath Assure – the Fastpath Assure solution offers a multitude of features that can help with security maintenance within the Security Designer module including the ability to upload a Security Configuration customization file and the ability to pick and choose which security layers you would like to migrate between D365FO instances. More information about the solution can be found here: https://www.gofastpath.com/erp/fastpath-for-d365-fo

A deeper dive into each component can be found here: https://learning.gofastpath.com/security-designer-for-d365-finance-and-operations

D365FO Security Converter 

A free tool I developed that helps perform the conversion from security created via configuration to security created in code, it also allows for selecting which security layers you would like to convert, you can find this solution on GitHub here: https://github.com/ameyer505/D365FOSecurityConverter

Conclusion

I hope the above post helps determine which D365FO security development option is best for your organization. If you have have questions about the above please feel free to leave a comment below or reach out via email.

The post D365FO Security Setup: Configuration or Code? appeared first on Alex Meyer.

Original Post https://alexdmeyer.com/2024/12/16/d365fo-security-setup-configuration-or-code/