You must be the change you wish to see in the world.
A custom workflow was published, but CRM continued to use the old custom workflow. This error frustrated the developer for a while before diagnosing the problem.
CRM developers must understand the CRM architecture and CRM SDK, the alternative is fixing problems using trial and error.
trial-and-error method of find solutions is a lottery, sometimes you find the solution quickly, other times you try many alternatives.
The CRM SDK is a map showing boundaries and location of major CRM SDK landmarks. Developers navigate the CRM landscape creating suitable customizations for customer requirements. CRM developers who don’t consult the CRM SDK (map) can get lost and not know how to get back on course.
A CRM developer updated a Custom workflow, published the custom workflow, but the old custom workflow was still running.
Experienced CRM developers will nod their head at this rite of passage.
The quick answer
Recycling the CRM app pool refreshed the custom workflow, doing an IISRESET resolve the problem.
Be careful recycling the CRM app pool or doing an IISRESET on production systems, it will disrupt users sessions. IISRESETS and CRM app pool recycle should be done out of hours where possible.
The reason this worked is the custom workflow had changed the parameters passed in.
Thinking is the hardest work there is, which is probably the reason why so few engage in it.
Learning how the CRM works, helps diagnose future problems and avoid making similar mistakes. The CRM developer centre is a great resource to help navigate the CRM SDK.
CRM developers benefit from learning the CRM SDK and CRM Developers should always start with the CRM SDK, understanding how it works and its quirks.
The better you understand how CRM works the fewer error/mistakes and dead ends you will make. Dead ends can waste time because
- Create a customization
- find it doesn’t work
- Remove customization
- Have to create another customization
Custom workflows and developer fear
CRM developers can fear custom workflows if they have never created one. Custom workflows share many characteristics of plugins but have some fundamental differences.
One of the main differences is how the Custom Workflow variables are passed in but the key difference is plugins must run within 2 minutes or the plugin times out, throws an error and rolls back any changes.
Custom workflows are often used for long running process.
The blog below is common Custom Workflow question
Before you have created a customization, there is a doubt you can successfully create the customization. The developer often has theoretical knowledge but not the practical experience.
The best method to remove this developer fear is to do it, it’s often not as difficult as your mind tells you it MIGHT be.
Why didn’t the Custom Workflow seem to publish
I remember this topic from a previous blog post
A Custom workflow is Asynchronous, running after the plugin execution pipeline has finished. Async processes (System Jobs) are managed by the Async Queue Manager which decides what System job runs next.
The Async processes can never guarantee when they will run because the Async Queue manager decides what is run. It could be 3 seconds or it could be 2 days (unlikely but possible).
Microsoft have a great page – Asynchronous service in Microsoft Dynamics CRM, all CRM developers should be made to read this.
To refresh my knowledge on Async plugins blog posts
Async process are
- Async plugins
- Custom Workflows
- Bulk Delete jobs
- System Jobs
- Bulk Import
The CRM Asynchronous Service runs on the CRM server services (it could be on the back end server)
Recycling the app pool/doing an IISRESET resolved the problem but why?. I looked towards the effects of IISRESET’s on plugins.
If you deploy plugins to the CRM database you should not need to restart the CRM async services or do an IISRESET.
To understand the effects of an IISREST read this post and the section What can you restart and how does it affect plugins.
In my example, I needed to to recycle the app pool/IISRESET, I found the answer article
There is one other scenario when you need to recycle the CrmAppPool application pool. If you modify the parameters that are available for a Custom Workflow Activity, then CRM will not make any new parameters available when editing the workflow until after recycling the application pool.
I think the reason the custom workflow wasn’t updating was because the parameter values might have changed.
Interesting facts on Custom Workflows
A great article on using versioning your Plugins and Custom Workflows
If you use versioning you will need to select the new version because both versions will now be deployed.
Some best practices/gotcha here – Asynchronous service in Microsoft Dynamics CRM
You should stop the asynchronous service before you unregister a plug-in that was registered to execute asynchronously. Stopping the service prevents a situation where an asynchronous registered plug-in has been queued for execution but for which there is no plug-in assembly currently registered. For example, consider the situation in which a plug-in has been registered to execute asynchronously and the related event has fired. After the asynchronous operation has been queued by the queue manager, you then unregister (delete) the plug-in assembly from the Microsoft Dynamics CRM database. In this case, an error occurs when the asynchronous service tries to execute the queued asynchronous operation but the plug-in assembly no longer exists.