You imported thousands of records into Dynamics 365 based on your customer’s needs and goals, and data provided. Since then, the customer has created activities and other relationships with these records. Then, the customer realizes there was some data left out of the initial migration for which they now know they need for business reasons. You can’t bulk delete the records and re-import as there is already production data that uses those records. And since there are thousands of these records, the standard method of exporting, merge changes and re-import isn’t really a viable solution.
The way that I’ve solved this problem is to use what I call a sideways update. (I’ve had to do this with more than 400K records before.) Essentially, I create a custom entity and set up an N:1 relationship to the entity in which records need to be updated. I can then import into that new entity and use workflows to update the records. Once all the records are updated, I can use a bulk delete to get rid of the import data. Here is a high-level process.
1. Update the Receiving Entity
The first thing to do is make sure that the entity for which the records need to be updated has fields for the data to be added. So, if you need to update Contacts with birthdays, you don’t need to do anything to the Contact record; it’s already got a birthday field. However, if you need to update Contacts with some custom data value, such as a custom option set for the highest level of education achieved, you will need to add this field. If it’s an option set, make sure you set this up as a global option set (as you will use it also on the custom entity and will need to map the two fields).
2. Create the Custom Entity
Once you have the data elements you need on the recipient entity, the next step is to create a custom entity and add those data elements to the custom entity. You may also want to create your own solution for this as well, just to keep it out of other solutions. Also, add an N:1 relationship with the recipient entity.
So, if you are adding birthdays to Contacts, you would need a date field and a lookup to Contacts. The important thing is to make sure you have a data element for each field that you need to update. Since you will be using this for updating from an import, you don’t need to spend much time building a form, however it may be valuable from a troubleshooting standpoint to add all the fields you are importing onto the main form so that you can validate it if something fails to update.
3. Create the Workflow
Next, you’ll need to create a workflow that runs from the custom entity on create and maps the fields to the receiving entity. The workflow should simply copy the field data imported from the custom entity to the appropriate receiving entity fields. However, you may want to only update a field if it doesn’t already have a value (if it was updated by another user and you don’t want to overwrite that person’s work). Also, as a general practice, I set up the workflow to run on demand and at the Organization scope. That way, I can run it manually if the workflow fails for some reason.
In the Update properties, you will map the fields from the custom entity to the receiving entity. If you are mapping from an option set that is not global, you will need to do that in a series of conditional statements.
4. Import the Updates
Now it’s time to import the updates. Import into the custom entity.
Then Map the fields according to the schema that you’ve set up.
While the import is occurring, monitor both the import …
… and the system jobs for the workflow (below is a sample query).
Delete Unneeded Items
Once the import is complete and the updates are made, you can delete the things you don’t need. If you don’t think this will ever happen again, you can delete the entity—remember to deactivate and delete the workflow first. Otherwise, you can us