How to: Move security configurations across Dynamics 365 environments

As you might know, security related topics are one of my favorites. It is not only about the technical stuff how to configure the roles. It is also related to e.g. segregation of duties to prevent possible fraud. It is always fun to work together with a customer to get the best possible setup which is manageable for the application support department. One of the tasks is moving new security configurations between environments.

In this post I will tell you how to do this, but also a neat trick how to rename newly created security objects as the Security configuration form is not supporting this.

Type of security changes

It is possible to do changes related to the security in several ways:

• Development in Visual Studio
• Configuration on runtime
• Combination of the two above.

There is a slight difference in Dynamics 365 compared to Dynamics AX 2012 for managing the security. In AX 2012, all security changes ended as security objects in the Application Object Tree (AOT). So, using several code deployment options, the changes were applied on e.g. the production environment. Development changes in Dynamics 365 needs to be treated similar. Using a deployable package, you can move the objects to a live system.

New in Dynamics 365 is the configuration on runtime. Changes are kept in the database and when publishing the security changes, objects are changes on runtime only. There is no link with the development environment. This does not mean that you would change the security configuration on your production environment directly. Changes needs to be tested first. As there might be a lot of changes which needs several test cycles and reconfigurations, the logging will be dirty and not very readable if there are too many changes. So, like other developments, it is recommended to start in a dev/test environment. The production environment will only get a cumulative, approved security configuration which is logged only once.

Move the security changes

When you have changes in security configuration which needs to be moved to another environment, you can simply use action buttons on the security configuration form. I will show the steps in detail.

To start with, I created a new security role: The Sales Assistant. This person is able to view customer details and allowed to maintain sales orders. When this role is tested and working as expected, we want to move it to another environment. To do so: Click Data > Export. The security changes will be exported in XML format which can be downloaded. You can store the configuration file within an own library.

Now you can open another environment where you can import the security configuration. Open the Security configuration form. Then click Data > Import. You will be prompted to specify a file name. The file you just saved would be the one which needs to be provided. Then click on OK.

The file will be processed and the changes will be visible on the form. On the Unpublished objects tab page, you will find all modifications.

In this case, I used standard duties. If there were more changes, you could see more objects and object types. Note that exporting the security configurations will export all configurations; not only the one you are focusing on. To be able to have the imported configuration active, you have to Publish all or select one or more records and Publish selected.

Renaming security objects

When you have made a mistake in typing a friendly name for a new security role, duty or privilege, there is an option to create a new object and use the correct name or spelling. However, if you are live, the references are based on internal ID’s. There is no option within the security configuration form to change the name once the object was created.

There is one simple trick which I tried once and this is working like a charm.

As described above, you can export the security settings and save the file on your computer. Then use an (XML) editor to open the file. When you don’t have such software, you can even use Notepad.

Note that the name of the role is a GUID ID. This ID is the primary key for letting the import know if a new role should be created or an existing one should be modified. All newly configured security objects do have such GUID where objects created in Visual Studio would have a readable object name.

When you have saved the file, you can import the file and publish the changes to correct the name(s).

That’s all for now. Till next time!

Microsoft Dynamics CommunitySubscribe to this blogger RSS FeedMy book on Merging global address book records in AX 2012

The post How to: Move security configurations across Dynamics 365 environments appeared first on Kaya Consulting.