Managing multiple Workflow Solutions

Let’s say that I have some really cool Workflow functionality that I created in Microsoft Dynamics CRM and I would like to reuse it in another environment and even possibly in multiple environments. Isn’t that easy to do? It should be but it may not be. This post will explain how to properly document and pull configurations over from one environment to another using solution file but not necessarily pulling over the entire underlying entities.

In my role as a Sales Engineer presenting Microsoft Dynamics CRM, I have built up a lot of little tid-bits of functionality that I like to incorporate into my demo’s. I have done a lot of work over the years with different ERP’s and CRM software packages and each have their pro’s and con’s on bringing elements from one environment to another. Microsoft Dynamics CRM 2011 does allow you to create solution files but it also requires all of the ‘possible’ entities and fields associated with your package to either be included in your package or at a minimum, all have to be in the target system. This isn’t ideal because you will have many custom fields and relationships in your source environment that you do not want to include in your solution file, which may have nothing to actually do with the functionality you are trying to replicate. Unlike some other CRM products, when you select an entity to be included in the solution file, Microsoft Dynamics CRM 2011 forces you to pull in the retire entity, you can not choose what fields \ relationships in the underlying entity yourself. As a result, if you have any 3rd party ISV’s installed, the export\import process of Microsoft Dynamics CRM 2011 will want them to be installed in your target environments as well…..This can be a mess in itself. If you have been working with the product for any length of time you will appreciate that last comment.

So how can I create a solution file from my source environment, then import it into a target environment? It may not be pretty but follow these steps and you will be able to replicate your work in target environments.

1. Document the CRM components of your solution.
   Yes I said document, it’s not a dirty word, it needs to be a required part of your work. Properly document every piece of your solution so that a year from now when you need the functionality, you can simply read through a document and know everything you did. In addition to documenting your fields and any values needed, process flow diagrams built in Visio and\or ppt are great. This documentation will prove to be required because when we get to building\importing in the target environment, your documentation will be used to as a guide to ‘recreate’ the needed fields in your target system that are directly involved in your functionality.
2. Create and export your solution file.
   Create a solution in your source system, naming it with something that signifies the underlying functionality. As you create the solution file, only select the Workflows that are directly involved in your functionality. When you get to the prompt to include required components, select the check box that reads “No, do not include required components“.
   
   If you have created custom fields that the solution needs to utilize, your target system will need to have those fields. There are a couple ways to do this but to keep it lean, you will recreate the custom fields manually in the target system. The reason this manual way is suggested is so that an entire entity with all the fields are not blindly pulled over, possibly overwriting existing work in your target system. Next you will export the solution file from the source system. You will be prompted with a screen that shows all the missing required fields that your solution needs.
   
   This screen is very useful showing you what needs to be in your target system in order for your solution to be imported. The last page in the set of wizard screens will ask you to export this as a managed or unmanaged solution. This is up to you but for rollback purposes you can export as a managed solution and easily roll it back if you want to take it out. Otherwise if you would like to possible change things in your target system after the import, then you should export this as an unmanaged solution.
3. Work in your target Environment
   First off, you need to recreate the custom fields that your workflows need in your target system. Refer to your documentation as well as the export dialog screen to know what needs to be in your target system. Secondly, import the solution file in your target system.
4. Import the solution in your target environment
   After you import the solution & publish, your target system will be set & ready to go. For future use of this solution file you will go to your documentation to understand what entities and respective fields are needed. Once you create these, you can import the solution with a comfort that you will not overwrite any existing work.