Migrating Security from Microsoft Dynamics 365 Finance and Supply Chain Management

Microsoft Dynamics 365 Finance and Supply Chain Management (D365 F&SCM) publishes security changes with new code releases. These changes are automatically applied to out-of-the-box security roles, duties and privileges when the code is upgraded in a given environment. However, manual migrations between development, test and production environments are required when maintaining a customized security design that complies with segregation of duty risks and contains custom objects. We would like to share our principles to approach security migration, known limitations in security migrations and use cases for two distinct types of migrations utilizing Fastpath Assure.  

Approach

• Allow a lower-tiered environment (development environment) to be the source of truth for production.
  • We recommend first making security changes/build in a development environment, migrating to a test environment for user acceptance testing and upon confirmation migrating into production, as per change management standards.
• Periodically export production security configuration as a backup.
  • We recommend storing a security backup in case of any faulty migrations or code updates to reduce business performance impacts from access issues. We have experienced instances where security is accidentally updated from an older environment without warning. This causes security regression, undoing previous changes made and leading to an excess of bugs submitted. Periodic exports of security prevent this issue. 
• Align code base between all environments.
  • If security objects are available in one environment and not another, the migration will not import any security object which does not exist in the receiving environment. This makes the source of truth a grey area. Please note the two instances below in which this situation may arise.
    • This can happen when a role is created directly in the production environment and the same name exists in the lower-tier environment. When importing security from the lower-tier environment to production, an error arose. Even though the security labels were the same, the system names were different. This means that the production role cannot be updated via security import.
    • If new custom objects are added in one environment but do not exist in future environments down the migration path, then security changes — including those custom objects — will not appear in the receiving environment since they do not exist. This could happen when new objects are evaluated in a user acceptance testing (UAT) environment, for instance, and is not yet available in production. This does not cause security migration errors; it just does not associate the nonexistent securable objects to the desired roles or privileges.
• Keep track of changes.
  • We recommend labeling security configuration imports with the migrated changes, the environment migrated from and the date to properly document changes.
  • During the hyper-care period for a security go-live, there may be numerous security migrations every day between environments, and sometimes to the same role. It is important to keep track of the order of these changes, especially when they impact the same role, duty or privilege since moving change out of order can cause security regression.

Limitations

One of the largest limitations to security migrations is that the out-of-box security migrations in D365 will only allow system administrators to migrate all the security from one environment into another. Because the system imports and exports the entire security configuration, thousands of objects import each time a security migration is complete, regardless of the scope of the changes. For instance, if one object is added to a privilege, the entire security migration will still need to be imported due to system limitations. This increases the margin of error as any changes made to other roles, duties or privileges that may not be ready to import will get picked up in the migration. Additionally, this process will result in every environment mirroring each other. This means test roles built in a development environment will appear in the production security configuration. It is ideal to have the test environment be a source of truth for production, but not necessarily the development environment. Due to these limitations, we recommend utilizing tools such as Fastpath’s Security Migrations feature (part of the Security Designer module) to migrate security via code or user interface (UI). The feature allows security administrators to only migrate the change made to a specific role, duty or privilege and provides the flexibility to migrate only the change(s) that are ready for testing.

Two methods of migrating security: Export to code and export to UI

Utilizing Fastpath, the migration is executed by first exporting security configuration within D365, importing the security to the Fastpath tool, selecting which roles, duties or privileges to migrate, then importing the file export into the appropriate D365 environment. Fastpath Security Migration allows for easy selection of roles, duties and privileges by system name and AOT name, exporting the file into XML to import directly in another D365 environment or exporting to code to be imported via code. Code migration allows for easier version control than XML and allows code to be migrated across multiple environments more quickly, however, it does require knowledge of Visual Studio whereas ‘export to UI’ is more user-friendly as it is done in the UI. Please see our steps below on how to complete these types of migration.

• In the development environment, export security configuration from D365 F&SCM (System Administration > Security > Security Configuration > Data > Export).

• In Fastpath, navigate to Security Designer > Security Migration. Click the + icon in the upper right of the Security Migration pane.

• Enter the security migrations name (i.e., 09/16/22 12:00pm, Dev to Prod, Adding All Customer page to Help Desk role).

Select the XML file exported in step 1. Click Save.

• Toggle on the roles, duties, and/or privileges to be migrated. Remember that toggling on an object will automatically grab all the associated security roles, duties and privileges.

Source: https://support.fastpathassure.com/hc/en-us/articles/360041124533 

• Reference either the code migration or UI migration section below dependent on the method selected for migration.

Code migration

• Click the down arrow next to the security migration and click ‘export to code.’ Graphical user interface, application

Source: https://support.fastpathassure.com/hc/en-us/articles/360041124533 

• From here, follow the normal steps for code migration. If a defined process does not exist, continue with the steps below.
• In Visual Studio, create a model for security; within that, create a security project with folders for roles, duties and privileges.
• Add the exported roles, duties and/or privileges from step 6 into the corresponding folders in Visual Studio.
• Synchronize the databases. To confirm that the changes were successful, open the uploaded environment and navigate to System Administration > Security Configuration. Filter for the roles/duties/privileges created and verify they now exist.

UI migration

• Select Export to UI

• Navigate to the D365 Security Configuration page and import the XML file generated through the Fastpath export.

• Roles, duties and privileges affected by the changes will appear in the “Unpublished Objects” header. Select “Publish All” to enable changes.

Security migration is a vital part of building security in D365 F&SCM. Understanding the different methods and their benefits can improve any security design approach. Using ‘export to UI’ is beneficial when building in the front end. However, when migrating across multiple environments or to maintain version control ‘export to code’ may be more useful. Utilizing Fastpath and these two methods will make security migration simpler.

To learn more about our Microsoft consulting solutions, contact us.