In a previous post, I showed how to set up security from the user interface. In this post I want to focus on D365FO security setup and configuration from the AOT.

Finding the AOT

The first thing we have to know is where the AOT is located in D365FO. In a development environment, the AOT can be accessed by RDP-ing to virtual machine where the AOS is hosted. On that machine will be a modified version of Visual Studio, under the View menu option you will find the Application Explorer (can also be launched by hitting Ctrl + E).

This will bring us to the AOT we are all familiar with.

Under the Security heading you will be able to find all roles, duties, and privileges that come out of the box from Microsoft as well as other roles, duties, and privileges that have been set up via the AOT. To create a custom role, duty, or privilege (or customize an out of the box role) you will need to create a new D365FO project. I recommend when creating this project to also create a separate model specifically for security and I’ll explain later on.

Creating a new security layer

If adding a new security layer right click -> Add New Item and select if you want to create a role, duty, or privilege. The name you provide will be the AOT name for the security layer you are creating, you can set the label for this later.

You can then start adding in subroles, duties, or privileges you want to associate with this new role by right clicking on that layer and selecting ‘New’. This process will allow you to create a new associations between the role and whatever child security layer you want.

You now need to provide the AOT name of the child security layer that you want to create the association with, in the example below we are creating an association between the FastpathTestRole and the ACOInquire_BR duty.

Modifying object access

If you are looking to create a privilege and want to actually modify object access you’re Properties window will look slightly different. In the below example, I created a FastpathTestPrivilege and assigned it the CustTableListPage menu item display at the Delete level.

In the Properties window, the Name, Access Level, Object Name, and Object Type parameters must all be set.

Modifying out of box security

You can also modify out of box security by creating an extension. In the Application Explorer search for the role, duty, or privilege you would like to modify, right click and select Create Extension.

You can then edit the out of box security. When creating an extension, you are not modifying the underlying object (like you would with over layering in previous versions of AX) but instead are creating an additional piece of data that is attached to the original object. In this way, Microsoft can update out of box roles, duties, and privileges without breaking customizations customers have already created.

In the example below, I am modifying the AuditPolicyManager role by add an association to the AccountantEntityMaintain privilege.

Synchronize changes with database

Just like with setting up security in the user interface, changes made to security in the AOT do not go live immediately. Since security is now stored as data in D365FO, there is a database sync process that needs to occur for your security to become live in the system. This can be done by right clicking on the Visual Studio project you have been making your security changes in and select ‘Synchronize <project> with database’.

Security configuration best practice

Now we can circle back and address why I said you should create a new model for just your security changes. If you have a separate model/project just for security you have the following advantages:

• Can more easily make security changes without effecting other areas of your environment, if all security changes happen within one project and it has it’s own separate module then you know when you build/sync the project you are only affecting security and not pushing unintended code into your environment
• Makes the security much more portable, if you have just a security model you can then create a deployable package from this and use that to apply to other environments very easily (just like you would with other code customizations)
• Makes it easier for source control and code management, with all of your security changes being in one place if anything needs to be changed there’s no guessing which project you need to update also because all of your changes you are making are code (and not data like it would be if you made changes to security in the user interface) you can use all of the benefits of source control around any changes

Conclusion

In my view, making changes to security in the AOT is a much better practice than modifying security in the front end but not every company is going to have an extra AX/D365FO developer that has the knowledge or time to be able to handle this. I hope these overviews of how to set up security in the user interface and AOT have been helpful, please feel free to reach out with any questions or if you have ideas of other topics I should cover.