Change Security In D365

Share this:

Microsoft Dynamics 365 for Finance and Operations has existing Roles set up. These roles are associated with Users and provide access to the Menu Items. The Menu Items allow users to run forms, reports, and batch jobs. There are times when you need to change Security In D365. Perhaps you need one Role to have access to a Menu Item that it does not by default. In this article, I will show you how to extend an existing Role to use a Menu Item that is not normally shown.

Review

Previously, I wrote the article Security in D365, which explains how security works. In it, I explain how Menu Items are grouped into a hierarchy of Privileges, Duties, and Roles. Afterwards, Users are assigned Roles. Roles provide users access to the Menu Items contained within those groupings.

In the next article, Customize Security In D365, I explained how to use the Security Configuration form. The Security Configuration form allows functional users to modify the existing security structure. Users can add existing Menu Items to different security nodes that they do not normally belong to.

However, using the Security Configuration has some limitations. Changes are stored in data. Therefore, it is not always clear who made the security changes and why. Additionally, in order to keep the security consistent across environments, the data must be exported and reimported to other environments.

Definitely, the Security Configuration form is very useful for non-technical users. However, the best place to make security changes is in the Application Explorer itself. These changes are made in code. And therefore, can be tracked using source control. And comments can be added as to why each change was made. Additionally, code can be promoted to different environments. And deployed along with all other customizations. Consequently, this helps ensure security is consistent across the environments.

In this article, I will explain how to change security in D365 using the Application Explorer.

Examples

To demonstrate how to use customize security in D365, I have come up with two examples. I will demonstrate the steps for these two examples. If desired, review the previous article to see the steps to do this using the Security Configuration form. In this article see the steps for making the changes in the Application Explorer in Visual Studio. These are the two examples I will cover. In this article I will just cover the first example.

  1. Add an existing menu item to a different existing Role. This is useful when you need a user to use a Menu Item that is not part of the Roles you have assigned them. It is also useful when it does not make sense to give the user access to an additional Role.
  2. Add a new Menu Item to to a new or existing Role. As a developer, you regularly will create new forms, reports, jobs, and more. In order to allow a user to use the new functionality you will need a Menu Item. Once you have a Menu Item created, that Menu Item needs to be added to either new or existing Security objects. This will allow users to access the Menu Item.

Add An Existing Menu Item To An Existing Role

Understand What Change Is Needed

The below examples should provide you the steps to follow for your situation as well. Simply replace the menu items, Privileges and roles with your scenario. The steps to follow should be the same.

For instance, let’s pretend you have a user that needs access to the Menu Item located at Accounts receivable>Setup>customer reason codes. But they do not have access to this form.

First, go to the System administration>Users form, and look at what Roles they have assigned to them. Pretend that they have the ‘Retail operations manager’ role. And it is this role that we wish to modify.

Secondly, go to the Accounts receivable>Setup>customer reason codes form and click on Options>Security diagnostics in the Ribbon Bar. Click the ‘Show object identifiers’ blue text. This form is included in the security objects listed.

The first question you need to ask yourself is this: Does it make sense to add one of the Roles listed to the User? Often, this is the case. And using the existing security structure makes the most sense. These Roles are defined based on what functionality users typically need access to as part of their duties. But let’s pretend that is not the case. And you need to customize security in D365.

Understanding The Security Object Names

If we see that using an existing Role will not work, then we need to change security in D365. In the end, we need two pieces of information. First, we need to know which Menu Item we need the user to access. And secondly, we need to know which Role to modify to include that Menu Item.

However, we can’t add a Menu Item directly to a Role. We need to add either a Duty or a Privilege that contains that Menu Item.

Using the security diagnostics form, see that the Customer reason codes Menu Item is part of the Privilege ‘Maintain customer reason codes‘. The Application Object name is ‘CustReasonsMaintain‘. It is also part of the Privilege ‘View customer reason codes’. Which has the Application Object name ‘CustReasonsView‘.

Therefore, we need to extend a Role to contain either one of these Privileges. Then, that Role will be able to view the Menu Items in that Privilege.

To summarize, we want the Role ‘Retail operations manager‘ to have access to the ‘Customer reason codes‘ Menu Item, which is contained within the CustReasonsMaintain and CustReasonView privilege.

Find The Security Role In The Application Explorer

Now that we know the names of the objects, we can change security in D365 using Visual Studio.

First, in a development environment, open Visual Studio.

Secondly, go to View>Application Explorer, in the Visual Studio menu.

Expand the node labeled ‘Security’.

This part of the AOT (Application Object Tree) shows you the security objects.

Expand the Security Roles node. All of the Roles will be shown.

However, the names listed in the AOT are different than the friendly label we saw on the Users form. In the Users form, we saw that the Role label was ‘Retail operations manager‘. On the other hand, when looking in the AOT, you will not see a node named exactly that. This is because you are seeing a label in the form, which is the text shown in the user’s language. Instead, the list you see in the Application Explorer is the node names. Names they have regardless of the user’s language.

That said, there are a few ways we can find the AOT name from the name we see on the Users form.

First, if you are viewing D365 in English, the AOT node names will often be a similar name without the spaces. For instance, if you search the list for ‘RetailOperationsManager‘ you will find it.

Secondly, go to System administration>Security>Security configuration. Then, under the grid labeled ‘Roles’, find and select the role ‘Retail operations manager‘.

Next, notice that the fields on the form have changed. The value under the field ‘AOT name’ shows the name of the node in the Application Explorer. In this case, it shows ‘RetailOperationsManager’. You can use this form to find the AOT node name of any Role in the system.

Extend The Security Role Using The Application Explorer

Now that we know the name of the Security Role within the Application Explorer, we can change security in D365 by extending the Role.

Notice the text between the square brackets to the right of the Role. It is ‘Application Suite‘. This tell us the Model that this object exists in. To learn more about Models, see this this related article. This Model is a base Microsoft Model. This means we are not allowed to modify it directly. We must extend the object.

Create A Project

Before we go further, we need a project that is set to the Model we wish this change to be made to. There are multiple ways to create a new project, and then create an extension. I will share my preferred way.

First, in Visual Studio, go to File>New>Project. I am using Visual Studio 2019. Your next screens may looks somewhat different.

Secondly, select the Finance Operations project template. Then click Next.

Thirdly, enter a value under ‘Project name’. Then click the Create button.

Fourthly, right click on the Project node in the Solution Explorer window, and select ‘Properties‘.

A dialog will open up. Finally, set the Model property to the name of the model you wish your changes to exist in. If you are not sure what this means, or need more help, see this article on how to create a model in D365. Click ‘Ok‘ to close the dialog.

Also, I recommend you set the ‘Synchronize Database on Build’ property to ‘True’. This is needed for security changes.

Extend The Security Role

Now that we have a Project that is set to use our Model, we can proceed with extending the Security Role.

To start, in the Application Explorer, right click on the Security Role you wish to extend. In our case, that is the role ‘Retail OperationsManager’. Then select ‘Create extension‘ from the drop down. Note: If you do not see this option, it is likely that you do not have a Project created and open. Do that first and come back.

An extension of this security Role will be added to your project. Right click on the node in the Solution Explorer and select ‘Open‘. A windows will open showing the details of this security role.

In this extension of the base security role, we can add additional Privileges and Duties that do not exist in the base Role.

In our case, we identified two Privileges that contain the Menu Item ‘Customer reason codes‘. Those Privileges are CustReasonsMaintain and CustReasonsView. After adding one of those privileges to this security role extension, users with this role will be able to see the ‘Customer reason codes‘ menu item. But which Privilege should we add?

Understanding Privilege Access Level

To understand that answer, first, go to Application Explorer. Search for CustReasons using the top bar. In the results, you will see both of these Privileges listed.

View

Next, right click the CustReasonsView Privilege and select ‘Open Designer’. A window will open showing the details.

After that, expand the ‘Entry Points’ node.

Next, select the ‘CustReasons‘ Menu Item from the list. In this case there is only one Menu Item in this Privilege.

Right click on CustReasons, and select Properties.

In the Properties window, you see will a Property named Access Level. The value of this property determine what the user can do on the form that this Menu Item opens.

In this case, the Access Level is set to Read. This means that the user is able to open and view the form. However, they do not have permission to update, create or delete the data.

According to best practices, Privileges that end in the word ‘View’, typically have the Access Level set to Read.

To understand further, any value set, will include the permissions of any value higher in the list. So for example, the Create Access Level, will include permissions to Update, and Read. But users will not be able to ‘Delete‘ records.

Maintain

Next, we will look at the other Privilege. Right click on ‘CustReasonsMaintain‘ Privilege from the Application Explorer and select ‘Open Designer‘.

After the window opens, expand the Entry Points node, and select the ‘CustReasons‘ Menu Item. Right click on ‘CustReasons‘ and select Properties.

In the Properties window, notice that the Access Level is set to Delete.

This means that Roles with this Privilege will provide users with the ability to Delete records on the form. In addition to creating, updating, and reading data on the form.

As a best practice, privileges that end in the word ‘Maintain‘, often have an Access Level of ‘Delete‘. However, this is not a rule and should always be reviewed.

The Microsoft documentation can viewed to learn more about the different Access Levels.

Add Privilege To Extended Role

Finally, we are ready to add a Privilege to the extended role. This is how to change security in D365.

Let us pretend we want our user to have access to Delete, Create, Update, and Read data on the Customer reason codes form. Therefore, we need to add the Privilege CustReasonsMaintain to our extended role.

First, right click on the RetailOperationsManager security role extension, from the Solution Explorer, and select ‘Open’.

In the window that opened, right click on the ‘Privileges’ node, and select

A new node will be created. In the Properties window, set the Name property to ‘CustReasonsMaintain‘. Consequently, this specifies the name of the Privilege to add.

Additionally, instead of adding the Privilege this way, you can also click and drag a Privilege node from the Application Explorer window to the Privileges node in the Security role extension window.

Synchronize The Database

Next, there is a very important step. You must synchronize the database. If you do not do this, the security role will not show up in your list of roles to add to a user.

To do this, right click on the project in Visual Studio, and select ‘Properties’.

Set the ‘Synchronize database on build‘ property to ‘True‘. Then, build you solution by going to Build>Build solution.

Summary

In this article, you learned how to change security in D365. I showed you how to locate a Role and Privileges in the Application Explorer. And I explained how to extend an existing role, and add an existing Privilege to that role extension.

Additionally, you learned that Entry Points on Privileges have different Access Levels, which determine what permissions a user has to interact with the data on the form. This is very useful, as you may have some users who should only be allowed to see the data on the form, but not change it. Whereas, other users will need full access to read, create, update, and delete the data on a form.

In the next article, I will explain the second example. Which explains how to create all the security objects needed for a new Menu Item.

Peter Ramer
Peter Ramer is a part of the Managed Application Services team at RSM working on Microsoft Dynamics 365. He focuses on the Retail and Commerce industries. When he is not solving problems and finding ways to accelerate his clients' business, he enjoys time with his three kids and amazing wife.

Share this:

5 thoughts on “Change Security In D365

Add yours

  1. I’ve always been encouraged never to change an existing, Microsoft-provided role – but to always create a custom renamed clone and to modify the latter only.

    I fear modding an existing one may unknowingly be a source of user role access conflicts and be much more difficult to explain to an auditor.

    The remainder of your article is really useful nonetheless 🙂

    Ian W.

    1. Thanks Ian. I very much agree. Creating a duplicate role and then modifying that duplicate is a great approach. I would definitely recommend that. Thanks for your comment.

Leave a Reply

Your email address will not be published. Required fields are marked *

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑