Designing Maintainable Workflows in Microsoft Dynamics CRM, Part 2

Non-technical users may come up with high value business ideas for complex workflows within Microsoft Dynamics CRM. In the previous part of this series on designing maintainable workflows, a six-staged structured methodology was introduced, of which the first three stages were covered:

1. A functional modeling language was introduced that can be used to describe complex business process in a high-level non-technical model.
2. This model was broken into smaller components through the process of box identification.
3. The creation of a status record was described to keep track of the progress of child workflows to control the progress of their parent workflows.

In this second and final part, the functional boxes will be translated into technical models (stage 4), that can be used to create the actual Dynamics CRM workflows (stage 5). The final stage encompasses the creation of a Starter Workflow to start the composite workflow. The series concludes with a discussion on advantages and disadvantages of this approach of creating maintainable workflows.

Stage 4: Create a technical model for each identified box

The previous stages described the identification of boxes that function as separate (child) workflows and the creation of a status record entity that maintains the connection between each of the (child) workflows. Next, each box is translated into a technical model. Just like the Functional Process Symbols are used to create functional models, the Technical Process Symbols are used to create technical blueprints of the workflows.

Technical Process Symbols

Besides functional process symbols - to capture business processes in diagrams interpretable by your customer - a set of technical process symbols is given below. The symbols serve as intermediate language ...