I was recently working with a customer who was getting an error when importing a solution into a CRM 2011 organization.  The solution was the default solution from an organization that had recently been upgraded from CRM 4.0, and the error was pointing to a specific Workflow that wouldn’t import.  After finding the workflow, we noticed a few things:

  • The workflow was actually a workflow template.
  • The workflow was calling a child workflow
  • In the workflow steps, when clicking on the child workflow an error appeared.  After further investigation, it was determined the child workflow no longer existed.
  • The owner of the workflow had since left the company and the person’s AD account had been removed.  The CRM user account existed of course but could not be used since the AD account no longer existed.

In an effort to take ownership of the workflow with an active user, we tried to assign the workflow using a CRM admin account.  However we received errors while doing this.  We then updated the original owner account by changing the active directory user to an active “dummy” account.  We then logged in with that dummy account and tried to edit the workflow.  We still got errors.  It was impossible to reassign, deactivate, or even delete the workflow no matter the user account.

The reason the solution was failing on this workflow was because the child workflow no longer existed.  However, the errors we were getting when attempting to edit the workflow were also because the child workflow no longer existed.

After further research, I discovered there is a difference between CRM 4.0 and 2011 in how child workflows relate to a parent workflow.  In CRM 4.0, if a parent workflow calls a child workflow, that child workflow can still be deleted.  And if so, the parent workflow handles this by allowing you to Unpublish the workflow and remove the child workflow step.  However, in CRM 2011, if you attempt to delete a child workflow that is being used by a parent workflow, you will receive an error and will be required to remove the child workflow from the parent workflow first.  What we were running into was a workflow state that should be impossible in CRM 2011, but since it was upgraded from CRM 4.0 it was possible.

There is little that can be done in a supported manner to fix this situation.  The best solution is to go back to the CRM 4.0 environment and fix the workflow first.  This could be removing the child workflow step in the parent, or remove the parent workflow altogether. Then upgrade the 4.0 organization to 2011 again and the problem should be resolved.  This underlies the importance of reviewing your CRM 4.0 data prior to upgrading to 2011, and testing after the upgrade, especially your workflows as shown in this case.  This workflow wasn’t even being used in 4.0 but caused an issue in 2011 after the upgrade.

For more information on Microsoft CRM upgrade best practices, see the CRM Implementation Guide.  Also refer to our Upgrade Readiness and Production Upgrade services listed in our Menu of Services and the CRM Upgrade Best Practices blog.

If you’d like to keep in touch with our team, you can follow us on our CRM in the Field blog as well as on Twitter and through our Podcasts.  If you have a Microsoft Premier support contract and wish to work with a member of our team, ask your TAM about the PFE offerings for Dynamics CRM.

Ryan Anderson

Microsoft Premier Field Engineer