Home > Blog > Identifying Roles for Security in Dynamics 365 for Operations

Identifying Roles for Security in Dynamics 365 for Operations

With Dynamics 365 for Operations comes change. And change is good, it helps keep us on our toes and gives us an opportunity to freshen up our skill sets. There is plenty of change with Dynamics 365 for Operations and one such opportunity to freshen up my security skillsets recently presented itself.

A client asked what role they needed to add a user to in order for the user to be able to run Process assortments from the Retail module.

The Process assortments link simply popped out a flyout form to run a batch job that executed the Retail Assortments Job.

A Quick Review - Security in Dynamics 365 for Operations

Security in Dynamics 365 for Operations is largely unchanged from Dynamics AX 2012. It’s still focused on role-based security with a minor new layer of Azure Active Directory as an authentication mechanism before the authorization piece. I’m not going to cover how security works in Dynamics 365 for Operations, but if you are interested in learning more, review the following links:

• Security architecture - https://ax.help.dynamics.com/en/wiki/security-architecture-of-the-microsoft-dynamics-ax-application/
• Role-based security - https://ax.help.dynamics.com/en/wiki/role-based-security-in-microsoft-dynamics-ax/

In a nutshell, this is how security is structured in Dynamics 365 for Operations:

Security Changes in Dynamics 365 for Operations

There are a few changes to security in Dynamics 365 for Operations, while not exhaustive, they are:

• Process Cycles have been removed
• Record Level Security is obsolete
• Security changes are stored as data when done from the UI

The root of all security is gained by placing users within a defined Security Role to grant them access to whatever it is they need access to (this is really simplifying security).  In Dynamics AX 2012, the old way of figuring out when a user didn’t have access to something (in this case that something is a menu item), you could do the following:

• Identify the area the user didn’t have access to
• Log into Dynamics AX as a sysadmin
• Right-click on it on the area, select personalize and identify what the object was
• Open the AOT and select the object (or find the root object)
• Use the Security tools add-in to View Related security roles report

This is a simplified overview of how you could determine what role a user might need to be added to gain access to an object (form, menu item, etc.)

Identifying What Roles Have Access to An Object

With Dynamics 365 for Operations, things have changed.  The old way of identifying what role(s) have access to an object is different, as the interface and client are different. Let’s circle back to the question at the start of this blog.

What role(s) have access to run the Process assortments job in Retail?

There were two ways this question could potentially be answered:

1. Use Task Recorder to create a recording of the steps in the process and then use Security diagnostics for task recordings (System Administration | Security) to review required permissions.
2. Use a developer machine, open Visual Studio and navigate through the AOT to find the object and default roles that have permission.

I started with option number one above, however, I found that the recording simply didn’t provide any security context information since it was a flyout and not a true form:

Here are the recording steps:

And here is what the Security diagnostics for task recordings showed (short version – total bust):

Option number two it is.

Identifying Roles in Visual Studio

To start I did the following:

1. Logged into a Developer Machined
2. Opened Visual Studio
3. Navigated to AOT | User Interface | Menus | RetailMain | RetailITMenu | ProductsAssortmentExploderJobScheduler

First I looked at the Properties window to determine what objects are involved.  In this case, it’s a Menu Item with a type of Action.

Next, I navigated to AOT | User Interface | Menu Items | Action | RetailAssortmentExploderJobScheduler

Then I right clicked on the menu action and selected Open designer

From the designer window, right click on the RetailAssortmentExploderJobScheduler and select Addins | View related roles

And here is the resulting report showing what Roles by default have access to this object thus answering the question what roles a user might need to be added to be able to run the Process Assortments job.

Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.

Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.