Migrating USD-configurations (e.g. action call records) from one environment to the next can be problematic. There are especially two things to be aware of:
1. The configuration migration tool might deploy records to the wrong server. If you are importing records to more than one server, you need to edit DataMigrationUtility.exe.config so it points to the correct environment. Look for “CrmServerName” and “CrmOrg”.
If you do not edit the file, this is what will happen:
a. Open CMT, log on to server A (e.g. the development-environment)
b. Export 2000 USD-records
c. Log on to server B (e.g the test-environment), import records
Result thus far: 2000 records are imported to server B
d. Log on to server C (e.g. the Q&A-environment), import records
e. Result: 10 000 records are imported to server B, none to C. CMT throws no error.
It seems that CMT will import to server B, then query server C to check if the import was successful, then repeat step 1 as the records haven’t been imported to server C. To avoid this happening, follow these steps:
a. Open CMT, log on to server A (development)
b. Export the records you need
c. Edit DataMigrationUtility.exe.config so it points to server B
d. Log on to server B, import records
e. Edit DataMigrationUtility.exe.config so it points to server C
f. Log on to server C, import records
2. Importing records is an additive process. This isn’t something new, but it can be especially challenging in regards to USD. As an example, lets imagine a scenario where you’d want to make some changes to a call script:
a. A call script is created with actions A, B and C. This is then deployed to the production environment.
b. In the development environment you remove action B and add a new action D. This is then deployed to the production environment.
c. The result now is that the call script in the production environment has all the actions (A, B, C and D), as the deployment did not delete any records.
If you remove a record in the development environment, you need to do the same in the other environments. It is possible to remove the USD-solution from the other environments before doing a new deploy (which will remove all records), but this is not always possible as it contains a reference to the user-entity (so there might be a conflict). Another way to circumvent this problem is to create an on-demand WFA that deletes all USD-configurations, which then can be executed before each deploy.