Monthly Archives: March 2018

Configuration Data Manager updates: improved lookup resolution, longer FetchXml, “applied on” date


Based on the feedback I got so far, there is an updated version of the configuration data manager solution:

Here is what’s included into this update:

  • You can use more than 2000 characters for the FetchXml
  • When importing configuration data, all non-existing references  will be removed. You can still get the lookups assigned properly if you first import “parent” data and, then, child data. Another option might be to run the import twice if the data is self-referenced in some way. During the first import, it’ll be imported without lookups. During the second import, it’ll be updated, and the lookups will be set correctly.
  • Finally, you can now see not only when the data was modified/prepared(“modified on” column), but, also, when it was applied/imported in the current organization:


Note: business unit – owned entities such as “teams” will be assigned to the root business unit during the import.

Dynamics Configuration Data Manager 1.0 – add configuration data to your solutions!


There are various tools out there we can use to move configuration data from one Dynamics environment to another, but what if we could add data directly to our solutions? So that there would be no need to run XrmToolBox, package deployer, SSIS, Scribe, or other tools in order to get our base data, always with the same guid-s, deployed? So that we would provide the solution file, and, once the solution has been imported, it would take just one click of a button, all in Dynamics, to get that data imported?

If this sounds remotely interesting, there is a tool I’ve been working on which you might want to try:


You can download it from here:


Here is how it works:

  • Using the tool, you can create different datasets. Those datasets are based on FetchXML, and you can give them priority order (When “Import All” option is selected, the dataset with the lowest order # will be deployed first. For example, if you have lookups somewhere, you might want to deploy your “parent” records first followed by the “child” records). Creating a new data set is simple – just click “New Data Set” button:image
  • Once you have a data set, you can prepare all data or just that particular data setimage
  • This is where there is some difference between “home” datasets  (those created in the current Dynamics organization) and external datasets. You cannot update external datasets – you can only load data from them.
  • For every dataset, there will be a web resourceimage

Once the datasets are there, and once you have prepared the data (using “Prepare All”, for example), you can include those web resources into a new/existing solution, and, then, bring them over to another environment.  As in the example below, I have two web resources included into a separate solution:


I might have included them into an existing solution – it does not matter. What matters is that, once you bring those web resources to the target environment, and if you have Configuration Data tool installed there as well, you can use “import all” option (or import each individual dataset separately) to deploy that data in the target environment:


For example.. I have no accounts here other than “test” account:


I am using “Import All”:


And now I do have the accounts:


As for the limitations.. The main limitation of this first version, is that it does not support N:N system entities and some of the more advanced data types (such as multiselect optionsets, activity parties, and/or customers).

And there is a bunch of improvements I can see right away (including ID mapping, solution mapping, more advanced lookup resolution mechanism, moving the whole thing to GitHub, etc).

Yes, there is some work to do for version 2. For now that’s what it is, though, so let me know what you think!