Dynamics CRM: Workflows revisited

In the third post of my Diving into the sales pipeline series, we covered the creation of workflows to handle the different stages (i.e.: pipeline phases) of the sales process. If you followed the series from the beginning, you would recall that in that example, we did not want users to be able to jump back and forth through the pipeline phases. For example, a user with an opportunity located in the first pipeline phase shouldn’t be able to jump forward without first passing through the second stage, or be able to move backwards in the sales process.

There are a number of reasons why I stuck with this requirement. First, the whole article series is based on the real requirements of one of my past clients, and the client strictly required users not to be able to move back or jump steps forward. Second, this requirement introduced a nice JScript (the bonus JScript in the second post of the series) which handles the hiding of options within an option set based on conditionals. There is a third reason, however. I must say that I was quite comfortable with such “inflexible” requirement: It made my job easier, and thus easier to document it in order to share it as part of the sales pipeline trilogy of articles.

There is a degree of mea culpa here. In the third post of the series, which covers workflow design, I asserted that the online workflow designer for Dynamics CRM doesn’t handle jumping back and forth through workflow stages, like the GOTO statement found in many programming languages. Although this statement is correct if we considering an orthodox view of what “GOTO” means from the mindset of a developer, it doesn’t mean that we couldn’t achieve similar results using the online workflow designer for Dynamics CRM. In this post I will be explaining how we can achieve such results using the online workflow designer.

Understanding linear and non-linear workflows

In order to implement a workflow that would allow users to go back and forth in the sales process, as well to jump stages, we must dissect a workflow and analyse all of its stages and actions in order to understand what is going on, and how the workflow is handled in Dynamics CRM. Consider the following “generic” example:

We need a workflow that will handle a sales pipeline divided into four stages. At each stage, the workflow will perform a given number of actions. These actions could be anything ,from updating fields on a record to sending an email to users. The workflow should then be on a waiting stage, waiting for either of the following to be true: The workflow to be cancelled (if the opportunity record is closed) or the user is moving to another stage.

A non-linear workflow

Let’s start by examining how a non-linear workflow, capable of jumping through stages (called “steps” in workflow lingo) would look like in this scenario. Consider the following workflow diagram:

In this diagram, when the move a stage, the workflow would jump straight to the relevant stage in the workflow, thus bypassing the stages in between. This is what I meant by a GOTO-like process. For example, if an opportunity record was in stage two (S2) and the user moves it to stage four (S4), the Stage 3 Actions would not be performed. At any given stage, the workflow is also monitoring for the opportunity to be closed. If that is the case, the workflow will jump to the “Stop Workflow” step. Additional actions could be performed at “Stop Workflow“, such as executing a child workflow, prior to cancelling the workflow.

Unfortunately, as previously mentioned, the online workflow designer doesn’t have an action to handle jumping workflow steps back and forth. We could however achieve this scenario by using XAML (Extensible Application Markup Language) workflows which can be created using Microsoft Visual studio. XAML allow a whole new level of workflow complexity, including integration with third party systems. However, Microsoft only recently enabled XAML workflow support in Dynamics CRM on-line, and to create such workflows one is required to have a certain knowledge of Visual Studio and .NET development paradigms.

A linear workflow

Despite such limitations, we could create a workflow that would allow users to effectively jump back and forward through the stages of the sales pipeline, yet keeping the workflow linear. Consider the following workflow diagram:

In this diagram, the workflow monitors the moving of the stages in two different grouping of conditions. That is, whether it is moving backwards of it is moving forward. If the user moved forward, the workflow will move through each of the workflow steps, without jumping any. For example, if the user moves from stage one (S1) to stage three (S3), the workflow will first move to the next step, which is stage two (S2). Then once it reaches stage two the Stage 2 Actions will take place, and since the user has in fact moved to stage three, the workflow will then move to the next stage. If the user move backwards in the process, the workflow will restart by executing another instance of itself as a child workflow, then cancel the current instance. Finally, like in the example in the linear workflow, at any given stage the workflow is also monitoring for the opportunity to be closed. If that is the case, the workflow will be stopped.

Designing the workflow

Let’s head back to the workflow we created on the sales pipeline series. The following screenshot is how the workflow used to look.

This workflow only have three steps, as to cover three stages of the sales pipeline. As you can see by looking at the screenshot, each workflow step can only handle moving to the next step. That is, from step one to step two, and from step two to step three. Not only the workflow can’t handle jumping steps (e.g.: from step one to step three), the workflow also can’t handle moving backwards in the process.

Have a second look at the workflow diagrams above and see if you can figure out what needs to be done. Here is how we do it:

Basically we need to modify the workflow to handle three different waiting conditions: Whether the user moves forward, backwards, or if the workflow is cancelled. Bearing in mind that at the first step the user can only move forward or cancel the workflow, and at the last stage the user can only move backwards or cancel the workflow.

Wrapping up

By combining multiple parallel wait branches and with the use of child workflows, we can design a workflow in Dynamics CRM that will be capable of handling users jumping around the sales pipeline phase, both forward and backwards. No need for XAML based workflows in Visual Studio. Hope you find this article useful. Enjoy!