1. Avoid broken references after deployment
   • Maintain the same GUIDs across environments for records referenced in workflows/views.
   • Use custom actions to parametrize the referenced records. Instead of directly referencing a record in the workflow, invoke a custom action that outputs the reference of record.
   

   Figure 1: Referencing record directly in workflow step.

   

   Figure 2: Referencing record retrieved dynamically by custom action in workflow step.

2. Submit multiple files for import at once with the .zip import method
   • If you have multiple data import files, importing them individually will be time-consuming. You’ll also have to ensure that the files are imported in the correct order to resolve inter-file column references
   • When you zip multiple files together for import, you save time and don’t have to worry about import order; Dynamics 365 takes care of it for you
3. Include only required fields in data import files to avoid unintentional plugin/workflow triggers
   • If you include unnecessary fields in the data import file, it’ll increase import time and might trigger workflows/plugins registered on those fields. For example, if you only want to update the address of your contacts, don’t include unnecessary fields like first name and last name in the import file.
4. Deactivate relevant plugins/workflows before bulk updating records to avoid unintentional triggers and reduce import time
   • When you just want to update data as part of data migration activities without triggering business logic, deactivate plugins/workflows registered on the entities present in import file. This will ensure that plugins/workflows are not triggered unintentionally while the data is updated.
5. Enable admin mode on your target environment before starting deployment
   • Admin mode locks the environment for all the users, meaning only system administrators have access during that time.
   • Enabling admin mode before deployment ensures that data is in a consistent state before and after deployment. This is useful in case you need to restore the data to its prior state.
   • During deployment, the system might be unresponsive and slow. This is why we recommended locking the system for end user.
   • While enabling admin mode, it’s highly recommended to add a user-friendly message for end users. This lets end users know that the environment is down due to planned activities, and the duration (downtime window) it will be down for. By doing this, you will avoid a flood of support tickets by confused end users.
   
   

   Note: Admin mode cannot be enabled on the production environment. In case you don’t have the appropriate permissions to convert the environment to a sandbox, use the global notification method instead to add a form notification for all users.

   

   Figure 3: Enabling Admin mode from Power Platform admin center.

6. Make a backup of the environment before starting deployment
   • Making a backup ensures that, in case of deployment failures, the system can be restored to its pre-deployment state.
   • Making a backup is faster than creating a copy of the environment.
   
   

   Note: When an environment is restored to an earlier state, the Data Export Service profile needs to be re-established to synchronize the Dynamics 365 data to Azure SQL.

   

   Figure 4: Creating a backup from Power Platform admin center.

7. Perform a dry run in a cloned production environment prior to production deployment to identify solution compatibility issues
   • Proactively identify solution compatibility issues by performing a dry run. That way, you can prepare a mitigation plan.
   • Dry runs ensure that any issues are flagged and resolved beforehand, mitigating end user impact.

References

We compiled our best practices from a mix of experience and research. For a detailed look at some of the points we mention above, we encourage you to go through the following documents:

• Copying records with GUID
• Invoke custom actions from a workflow