Synchronous On-Demand Workflows in Dynamics CRM 2011

Previously, I talked about building a work process in CRM 2011 if you are unable to move to CRM 2013 and make use of the new process flow functionality. In this blog I talk about another way you can approximate CRM 2013 functionality in CRM 2011. Specifically, how to create synchronous on-demand workflows in CRM 2011.

Workflows 101

Anyone who has worked with workflows in CRM 2011 knows that they run asynchronously i.e. not in real time. The workflow is triggered and then put in a queue for processing by the Asynchronous Service when the opportunity arises (generally within a few seconds of hitting the queue). This means that, for example, if my workflow creates a record, this record may not be immediately available to the user when the workflow is triggered. This can cause confusion but is usually managed as part of the training process.

The Traditional Workaround

To get around this issue, the best approach is code. For form behaviours, there is jscript and for record management there are plugins. However, if you are looking for a codeless alternative, albeit, as usual, a slightly less elegant one, here it is.

Pageless Dialogs: 2011’s Synchronous Workflow

Unlike their cousin the workflow, dialogs run synchronously. Unfortunately an in-built requirement of dialogs is that they contain a page and a prompt and response.

So how do we get around this? The simplest way is to embed a Prompt and Response in an If Statement and make it so that the If Statement is never satisfied. By the way, I remember reading about the possibility of circumventing the Prompt and Response on a blog years ago but cannot remember the source so, if this is you, thank you for providing this trick and giving me the mental foundation for this workaround.

So, for example, if we want to synchronously update a field, we can do this:

We will still need to manually refresh the form to see the change but the change itself will be synchronous. Other things we may want to do synchronously include:

• Create a record
• Assign a record
• Change status

Pros and Cons

As previously mentioned, a coded approach is a lot more elegant in terms of visibility to the end user; code behaviours just happen. In the case of my approach, the user must select the dialog and click the Finish button when the dialog is finished but when they have done this we can guarantee the changes have been applied.

Given dialogs can only be triggered on-demand, we are restricted to only creating on-demand synchronous workflows; for event-based workflows our only option for making them synchronous is still code.

One big advantage though is the ability to access the additional steps and functionality in dialogs, not available in workflows such as CRM Query, Variables and the ability to pass arguments to child dialogs. These are powerful functions and it is a shame that, even in CRM 2013, workflows do not have access to these functions.

Conclusions

Obviously, the best approach is to move to CRM 2013. However, if this is not an option, and you are loathe to write code for something which may well become obsolete when you eventually upgrade, this trick provides a codeless workaround to common CRM process requirements where the process is initiated by the user and needs to run in real time.