So you have built a Dynamics CRM 2013 workflow that creates activities and assigns them to work queues for processing. You have built and tested this workflow in your development environment, and you are ready to deploy to your production environment. You export your solution and import to your production environment only to find that all references to the queues are now invalid.

Unfortunately, Dynamics CRM does not include queues as part of a solution. In order to import a solution that has references to queues, you first must import the queues from your development system. The Dynamics CRM out of the box import facility will not import the GUID identifiers for new records, so it is insufficient for this purpose. If you have Scribe or another import tool, these may be used to import the queue records between systems. If not, then you need to find another solution to import the queues.

Fortunately, there is a straightforward workaround for this issue. The Linqpad plugin for Dynamics CRM can be used to create a script to install the queue records using the same GUID used in development. You will need to have LinqPad, the Microsoft Dynamics CRM plugin for LinqPad, the CRM 2013 SDK, and Windows Identity Foundation installed. All of these tools are free, and are probably already a part of your CRM development toolset.

In order to create our script, first you will require the GUID values used for these queues on development. To obtain these, you should use the export facility in CRM to export the queues, making sure to export a static worksheet made available for re-importing.

You can then open the exported file in either notepad or Microsoft Excel in order to retrieve the internal GUID values. With Excel, the columns will initially be hidden, so you should unhide the first column in order to access the GUID values.

Once you have the GUID values, you can now write a script that may be used from LinqPad to create the queues in your production environment. You start by opening LinqPad and creating a connection to your production CRM environment (this requires the CRM plugin for LinqPad, which may be downloaded from the LinqPad home page). Then you set references to the following assemblies from the Dynamics CRM SDK:

  • Microoft.Crm.Sdk.Proxy.dll
  • Microsoft.Xrm.Client.dll
  • Microsoft.Xrm.Sdk.dll

On the Addiional Namespace Imports tab, add Microsoft.Xrm.Client and Microsoft.Xrm.Sdk. You may then use the C# statements setting to add C# statements that will add the queues. You can use the OrgServiceWrapper object that is built into the CRM plugin to execute the updates. You should set whatever properties you require, but at a minimum the queueid and name properties must be set.

// This script will create the required queues 
// Note that the queues must be created with the specific GUIDS in 
// order to insure that the workflows work correctly 
Entity newq1 = new Entity("queue"); 
newq1["queueid"] = new Guid("62fd0010-106f-e311-93fe-000c29b4430a"); 
newq1["name"] = "Queue One"; 
OrgServiceWrapper.Create(newq1); 
 
Entity newq2 = new Entity("queue"); 
newq2["queueid"] = new Guid("64fd0010-106f-e311-93fe-000c29b4430a"); 
newq2["name"] = "Queue Two"; 
OrgServiceWrapper.Create(newq2); 

At this point you may execute the script against your production CRM environment. The script will create the queues with the same internal identifiers used in your development environment. Now when you import the solution, the workflows using these queues will import without issues. This same technique can be used for any other data that is referenced in workflows, such as users or contacts that are used in email activities.