Designing Maintainable Workflows in Microsoft Dynamics CRM, Part 1

December 10 2012

The powerful and user-friendly workflow solution in Microsoft Dynamics CRM can be leveraged to easily build relatively straightforward business processes. However, when business processes become more complex, the effort required to translate them into a maintainable workflow increases disproportionately. This two-part article provides practical guidelines for translating complex business processes into maintainable, easily testable workflows.

Helping the business get their complex workflows

While working on a large enterprise Dynamics CRM solution, we were handed seven PowerPoint slides containing nearly one hundred human tasks. The tasks were part of two key business processes. Many of the tasks were to be executed in parallel, some were to be executed conditionally, and others functioned as approval tasks - only to be executed once the preceding tasks were canceled or completed. The processes even contained multiple recursions. Of course, each task had it is unique details, such as the owner to whom it should be assigned and due dates that were dependent on fields in CRM.

It quickly became apparent that simply building a large workflow would not result in a maintainable solution, should it even be possible at all. A more structured approach was required that would be resilient to change and where the workflow execution state could be understood at a glance.

In an attempt to make effective use of our computer science background, we decided to take a more academic approach to formalize complex business processes - written by domain experts - into a model decomposition where each model could be implemented using a CRM workflow.  Here we share our methodology and experiences.

Reduced maintainability of larger workflows

Dynamics CRM workflows provide great flexibility and extensibility for automation of system-driven business processes. Conditional checks, waits and branches provide for enough expressiveness to implement most business processes. Custom workflow activities can be leveraged when things get really complicated. These tools are especially applicable to smaller workflows; larger workflows tend to come with challenges in maintainability. Workflows can be considered maintainable when:

  • It is possible to quickly grasp its functional intent
    This becomes increasingly difficult when depth of the workflow steps increase or when there is recursion involved in the workflow steps. Recursion means steps may need to be looped until a certain condition is met.
  • Grasping the current execution state of a workflow (set) does not take much effort
    Dynamics CRM provides out-of-the-box functionality to see the current execution state for one workflow. But this does not help the system administrator in great detail when multiple workflows depend on each other.
  • Small changes do not impact a large portion of the workflow
    Many developers that have built workflows with CRM are familiar with the frustration where you have to delete and rebuild a workflow branch, because the "Insert Before step" did not do the trick in accommodating the required change.
  • Long running and complex (multi-staged) workflows can be changed without disrupting operation
    Without proper planning ahead, it may be necessary to let the old workflow instances finish while the new instances run in parallel. This is not always acceptable for the business.


To overcome the maintainability issues of larger workflows and to help in the process of implementing complex business processes, we have adopted a six-staged structured methodology:

  1. Capture the desired functionality of the workflows in a model using a functional language that can be easily understood by the customer and the developers.
  2. The functional model is used to break up the monolithic large workflow into smaller and more maintainable workflows.
  3. Create a status record that tracks completion details of the individual workflows. The record shows the total progress of the combined workflow.
  4. Each of those workflows is described in a technical model.
  5. Each technical model allows for translation into an actual CRM workflow.
  6. Create the Starter Workflow to initialize the composite workflow.

A more detailed explanation of each stage is given below.

Stage 1: Design Functional Model

The idea for a workflow frequently arises at non-technical users. Our experience is that these users are perfectly capable of creating a schematic view of their desired business processes. Their schematic views can be used to discuss the flow and act as a starting point for the technical workflow. Among many different customers, we have found that they all came up with comparable notations. We collected them into a uniform set of functional process symbols.

Functional Process Symbols

Functional process symbols describe the business process from a functional point of view. The representation is used as an input for the translation from a business process into a workflow. The symbols should be seen as an accessible notation for the customer to define their processes. Although not obligatory, getting a design based on these symbols may speed up your work in translating it into a technical design.

To increase diagram readability, we chose to let the customer describe details of actions or tasks (for example, start date, priority, subject, etc.) in a separate document. Letters and digits were used as a reference between the two design artifacts.

Functional process symbols for Microsoft Dynamics CRM workflow design
Figure 1: Legend of functional process symbols



Start of diagram

Indicates start of the business process.


A state indicates a task or action to perform or finish to be able to take the next transition.


A branch models the paths and their preconditions that could be traversed. Only 1 path can be traversed simultaneously. A branch does not represent an action or task.


A transition models a possible one-way path from one state to another or to a branch. The transition could hold a guard that models the precondition required to traverse the path. For example, the completion of a task, the passing of a certain amount of time, etc.

Parallel activity streams start

This one-to-many fork models multiple activity paths that take place in parallel.

Parallel activity streams convergence

This many-to-one fork models the convergence of multiple parallel paths. The outgoing path can only be traversed when all parallel paths are finished.

Using Functional Process Symbols to create schematic views

The customer uses the functional process symbols to create schematic views of their business processes. The most common situations and their compositions are provided below.

Situation description

Schematic view

Sequential execution of workflow items.

Sequential execution of workflow items.

Parallel execution of workflow items.

Parallel execution of workflow items.

Repeat a workflow item until a condition is met (e.g. ensure that an end-user entered a valid value in a record).

Workflow loop

The first state is a task or an action to be performed by a person. The second tasks is assigned to a supervising entity, and is meant to make a judgment about the outcome of the first state. If undesirable, the state or action is to be performed again (e.g. useful in an approval flow).

workflow approval flow

Repeat a set of workflow items from the beginning each time the outcome of a task or action was not desirable (e.g. a complex approval flow with multiple approvers).

workflow multiple approvers

Wait until a specific point in time is reached.

Workflow wait to specific date/time

Stage 2: Box Identification - Identifying child workflows

When a schematic view of the desired business process is complete, the next step is to break up the view into smaller, workable components. The task is to identify the areas that must be modeled as child workflows within the main workflow to encapsulate the entire business process. These areas are called boxes. The procedure of finding them in a business process flow is called box identification. Box identification is characterized by finding the right start and end of a box.  Let's look at the mechanics of this process in more detail, as well as an example.

Finding the start of a box

A box should have one incoming and one outgoing transition. Breaking up the business process into smaller boxes is done by traversing the business process path from the start. Three situations have been identified as good fits for a new box. While traversing the path:

  • A branch element is encountered.
  • A state is found that has an incoming transition from a state that has not been traversed yet; the transition is a recursive call from a child element.

Finding the end of a box

The end of the box depends on the situation that started the creation of a box.

  1. For a box that was created after encountering a branch element, the end of it is marked by the first transition that is traversed by all possible paths that started after the branch element.
  2. For a box identified by a recursive call, its end is identified recursively:
    1. Include all possible states between the start state of the box and the state making the recursive call to the start state, including the start state and the state making the recursive call.
    2. If this set of states has any state making a recursive call to a state that is not yet in the box, repeat step A for these states, also including them in the box.
    3. Repeat this process until there are no more recursive calls found.

The resulting set of states together form the box.

Box identification example

Microsoft Dynamics CRM workflow box identification
Figure 3: An example of box identification that breaks down one large functional process design into smaller boxes. Each box eventually results in a CRM workflow.

Figure 3 shows a large functional process design. The black box covers the entire business process or Complete Workflow; it is the main workflow and will be the first box (1) (see Figure 4). Within the black box, traverse the path until the branch element is found, indicating the need for a new box (2): Subflow A. The end of Subflow A is found by the first single transition going out of the box.

Microsoft Dynamics CRM box identification breakdown
Figure 4: Breakdown into three boxes

Within Subflow A, observe there is yet another branch element in the business process. The blue box indicates a child workflow (Subflow A') of Subflow A: box 3. The end of Subflow A' is also found by identifying the single arrow going out of the box.

Stage 3: Design and Build Status Record Entity

Due to the lack of a native CRM mechanism to have a workflow pause while a child workflow runs, we have devised our own method to track the execution state of a child workflow. We have done this by means of defining a custom entity for the composite workflow, called the status record entity. The idea is to have this status record entity contain a number of datetime fields equal to the number of workflows identified in stage 2 that are to be waited upon. The names of these fields on the status record entity should preferably be descriptive for the child workflow that is to be waited upon for better readability.

After initiating a child workflow, the parent workflow will pause until the status record field corresponding to the child workflow is filled with a datetime.

After execution, the child workflow will set the value of its status record field to the current date and time and then end. This signals the parent workflow to resume duty.

The primary entity of the workflow is linked to the status record by means of a new field preferably hidden from the entities forms. The status record is initiated at the start of the overhead workflow.

It can frequently occur that a parent workflow resume after waiting (because the child workflow has set the date and time in the appropriate field), and see that the result of the child workflow is not satisfactory. When the child workflow is to be run again, the value in the status record field should be emptied before initiating the child workflow.

Note that when a child workflow is a ‘fire and forget' workflow, it will not need representation in the status record entity.


Part one of this article on designing maintainable workflows described several maintainability issues of large monolithic workflows. Non-technical users may come up with complex workflows that have high business value, but they are often not capable in translating them into the actual Dynamics CRM workflows.

A functional modelling language was introduced to allow those users to write down their desired processes in such way that it can be translated into a maintainable set of Dynamics CRM workflows. After creating the functional model, the next step in creating the workflows is breaking up the large model into smaller child workflow through a process called box identification. The first real technical step described the introduction of a status record entity to keep track of the progress of each of the child workflows, such that their parent workflows know when they can continue.

In the next and final part, we will look at how identified functional boxes can be translated into the actual Dynamics CRM workflows.

FREE Membership Required to View Full Content:

Become a MemberLogin
Joining gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more, and it’s all FREE. You’ll also have the option to receive periodic email newsletters with the latest relevant articles and content updates. Learn more about us here
About Sander Bockting

Sander Bockting is a CRM Consultant at Avanade Netherlands. He obtained his masters degree in Computer Science at the University of Twente with multiple scientific publications, mainly on information retrieval. With years of experience in the field of enterprise scale Dynamics CRM implementations, Sander was technical editor of the "Microsoft Dynamics CRM 2011 Administration Bible" and frequently speaks on CRM events. He is also a passionate photographer.

Avanade is a multinational consulting company founded as a joint venture between Accenture and Microsoft. Avanade delivers Microsoft Dynamics® CRM, ERP, cloud, business intelligence, application development, collaboration and outsourcing solutions to companies across the globe. For more information on our CRM ServiceLine click

More about Sander Bockting