June 23, 2016 – Hosk's Dynamic Blog

Everyone wants to learn the same thing from painful situations: how to avoid repeating them.

Gary Zukav

I worked on a CRM project where the configuration data had different guids between CRM environments. The project contained 10 complex workflows which referenced these records in CRM, when deploying, the workflows were manually repointed to select the records in each CRM environment, this manual step could take between 30 to 60 minutes.

In this post I discuss the role of guids, how to avoid workflow problems using the CRM configuration data mover tool which creates data in a different CRM instance with the same guid.

The task

Importing 300 opportunities from a CRM 2015 Online instance to a CRM 2016 online instance. There wasn’t much data, the customer didn’t want to pay so I used free solutions and not Kingsway SSIS or Scribe

Instead I am using the excellent Lucas Alexander’s Dynamics CRM Configuration Data Mover v1.10.

If you have never used the Dynamics CRM Configuration Data Mover read the introduction blog page below

Introducing the Alexander Development Dynamics CRM Configuration Data Mover

The purpose of the data mover is to move data between CRM instances and the records keep the same guids.

Why is it important to keep the same guids?

Guids are unique identifiers (guid stands for Global unique identifer) and when you create a new record, CRM automatically creates them for you. Every record in CRM has a guid, these are used in lookups when selecting records.

A lookup record is an EntityReference, which has the entity type and guid. In my Hosk Dev tip I recommend you always add an ID suffix to lookup fields so they are easy to spot

Hosk CRM Dev Tip – add ID suffix to lookup fields

Once you get the guid of a record you can use this in code to retrieve details on the record and use it whilst debugging your code. One reason why CRM developers want to retrieve the guid of a record – Quick way to get the guid on a form, my current favourite way is using bookmarklets

When you import data into a new CRM instance it creates the records and assign those records new guids.

Records with the same name but different guids cause problems in workflows which use lookup fields. Inside those lookup it has a guid which doesn’t exist in different instances of CRM and the workflows won’t work. The workflows show you this by unpublishing themselves when deployed in a solution to a new CRM environment.

If you use the CRM configuration data mover it copies the records across and the data has the same guids..

CRM configuration data mover highlights

I will cover the CRM configuration data mover in more detail in a future blog post but here are a few highlights

You use FetchXML to retrieve records, this allows you to filter record you want to copy
It has an update and create checkbox for each step
It easily syncs data between CRM instances with a push of one button
You can move Access teams (currently no way to export/import access team templates between CRM instances – Why are access teams marooned?, also read The benefits of Access Teams)
It can be run from command line to make it part of your build
It makes the build process easy
It keeps the same guids
It can map guids of records used e.g. user records

I wouldn’t recommend this tool to copy lots of data across, it not designed for bulk copying and might result in a situation where half the data has copied across.

Configuration record

A different way to avoid the guid problem is to create a configuration/System Settings entity which you can use to hold global settings used in your customisations.

Having a configuration entity encourages developers to put global configurations in the entity rather than inside the code or on each entity. Standard approaches to development make it easier for teams to create one solution and easier to debug.

A configuration entity is easier for the team to the global configuration settings which when changed and can cause CRM to act in an unexpected way.

I have seen CRM teams create one entity and add fields as needed but I prefer to create a simple entity with a name and value field. This way you can add more configuration settings by creating record rather than having to update an entity and add fields. What ever system you use this code should be standard code used in different projects, this allows you to create reusable code and customisations. Why isn’t code reused in Microsoft Dynamic CRM projects?

The reason this stops the workflow guid problem is workflows reference a field on the configuration entity which you can set at runtime and configure once on each environment. When you change a workflow it will point to the configuration entity which is the same in each environment.

This method encapsulates what changes and separating it from the rest of CRM.

Manual method

It‘s possible to export records from Microsoft Dynamics CRM, tick the import button, save the record as a CSV. This will give you the guid for each record in the export (explaining how the enrich/import data works, it uses the good to reimport the data to the correct record).

The records are imported, setting the guid for each record, keeping the same guid between CRM instances. This method works but involves manual manipulation of excel records and CRM developers have better, more interesting things to do.

I have worked on projects in the past which created its own import/export console app, this worked but many hours were spent maintaining and debugging the tool. It’s better to use the Dynamics CRM Configuration Data Mover.

Get a deployment process

Data copying and keeping CRM instances in sync is important but its one of many parts of a deployment process.

You need a standard deployment process. Deployment process and checklists are great with repeatable static lists of tasks where you need to do multiple steps in a set order. Read the blog post below for ideas

CRM 2015 – Best practices for CRM Deployments

You should automate as much of the deployment process as possible, this