Microsoft Dynamics CRM is highly customizable and can be used to reproduce/automate business processes.   For someone familiar with the basic use and implementation of workflow processes in Dynamics CRM, creating short workflow processes can be attained by simply inserting a couple of steps and check conditions.  But when business processes become complex, it can become daunting and without planning, you can end up wasting a lot of time designing and re-designing the workflow.

My general approach to planning a CRM workflow process is:

Part 1

• Identify the Business Requirements
• Visually model the Business Requirements

Part 2

• Translate the Business Requirements into CRM workflow processes
  • Initial CRM Planning
    • Create forms and fields
    • Identify triggers that start the CRM workflow process
  • Convert the Business Requirements into Dynamics CRM workflow processes that account for all possible cases
  • Identify duplicate processes
  • Identify CRM workflow process loops
  • Simplify CRM workflow processes

Based upon a real life scenario, in Part 1 of this post, I discussed identifying and modeling the business requirements.  Now in Part 2, I will discuss translating the business requirements model into full-fledged CRM workflows.

Scenario

One of the business units in a company is working on a new venture with a series of manufacturers and needs to ensure that the manufacturers are being compliant.  They have placed auditors in distribution centers, but need a system to track/report on passed audits and the communications regarding compliance progress (or lack thereof.)  They intend to classify the manufacturers by status (red, yellow and green) to help determine which manufacturers are in compliance, and which might be troublesome.

Translate the Business Requirements into CRM workflow processes

Initial CRM Planning

Now that the business processes have been outlined, we need to identify the fields for form design.

Scenario fields:

• Audit Start Date
• 1^st Passed Audit Date
• 2^nd Passed Audit Date
• 3^rd Passed Audit Date

To begin planning the translation from business processes to CRM workflow processes, identify the trigger that starts the CRM workflow – for this scenario, the trigger is when the Audit Start Date is changed.

Convert the Business Requirements into Dynamics CRM workflow processes that account for all possible cases

CRM workflows must be more explicit than typical business process because they must not only account for what should happen, but also for what should not happen.  They need to include early exits and account for all possible cases.  At first glance it seems that all the workflows, when looked at independently, seem simple to implement.  The Passed Audit Process and Status Update Process are simple enough, because there are few decision points (or Check Processes) and there are no looping processes.  The Audit Progress Process is more complex because it requires that a task be auto-created every five days until the next audit is passed, and it has multiple decision points.  Also, to ensure the most efficient path is used, you must plan for different cases that may occur.  For instance, what happens when a manufacturer completes all three audits before the first task is supposed to be auto-created? The workflow must account for all possible cases, at all times.  (In reality, this may not be realistic.  But designing your workflows with the 80/20 rule in mind and having a firm understanding of their function will help greatly in troubleshooting later.)

All of a sudden, this simple business process…

…quickly morphs into this complex CRM workflow process.

NOTE:  The below describes the annotations used in the model:

• P1 = 1^st Passed Audit
• P2 = 2^nd Passed Audit
• P3 = 3^rd Passed Audit

This model depicts every possible case that could happen at any possible point in the business process, but don’t fret!  You will not have to re-create the entire model, if you plan appropriately.  In fact, if you take a closer look, you can clearly see that there is quite a bit of duplication in the model.  We can use this to our advantage.

Identify duplicate processes

Next we need to identify duplicate processes.  When taking a closer at the model, you will notice that there are two major chunks of this process that are repeated in other parts of the process.  For instance:

• The check to see if the 2^nd Audit has passed is duplicated in two places – I named this “P2 Check”

• And the check to see if the 3^rd Audit has passed is duplicated in five places – I named this “P3 Check”

Identify CRM workflow process loops

Next, identify any CRM workflow process loops.  This scenario requires the CSR to make a call to the manufacturer until they pass another audit.  A loop in a Dynamics CRM workflow is easily created by having a Child Process call itself at the end.   For convenience’s sake, I will call these the “Reminder” workflows.  However, these loops are not exactly the same, because the exit check conditions vary slightly (there is a check condition for each of the passed audits: P1, P2 and P3).  Later, these can be simplified so that they only need to be created once and the other CRM workflows processes can simply call them.  It should also be noted that the “Reminder” CRM workflow process are located within the “Check” process, so each “Reminder” CRM workflow process will actually be called (or started by) the “Check” CRM workflow process.

Simplify CRM workflow processes

Now that we understand the “Check” CRM workflow processes, the model can be made much simpler. Here is a more simplified CRM workflow process for the Auditing Progress Process

If you skipped the planning phase, and went straight to designing in Dynamics CRM, you likely would have ended up kicking yourself about three hours into the design, realizing you need to account for all the other cases.  Not only does failing to plan cause sleepless nights and headaches, it also results in a needless duplication of effort.  This model gives us exactly what needs to happen, when it needs to happen.

Some people may feel that they don’t need to plan or they just don’t have the time to do so.  Planning a Dynamics CRM workflow process before design versus just jumping into design is much like driving without a map versus having navigation on your GPS.  If you don’t have time to get lost and have an adventure, then you don’t have time NOT to plan!

Chris C. has been with ECI since 2010. Being a fully certified Microsoft Applications Consultant in Dynamics AX and Dynamics CRM, you will find him at the intersection of Business & Computing bridging the gaps between People, Technology and Business Processes.

Microsoft Dynamics CRM is highly customizable and can be used to reproduce and automate business processes.   For someone familiar with the basic use and implementation of workflow processes in Dynamics CRM, creating short workflow processes can be attained by simply inserting a couple of steps and check conditions.  But when business processes become complex, it can become daunting and without planning, you can end up wasting a lot of time designing and re-designing the workflow. 

This blog post does not introduce any new, radical IT concepts.  In fact, its major takeaway reinforces the common IT mantra of PLAN, PLAN, PLAN!  But how do you plan a Dynamics CRM workflow process – especially when they seem so easy in your head?

The purpose of this post is to provide a system for planning and understanding what you are trying to accomplish, minimizing rework by not creating needless workflows, and identifying pieces of the workflow that can be reused.  This post will provide my personal approach to planning a Dynamics CRM workflow process and apply to a real-life scenario.

My general approach to planning a CRM workflow process is:

Part 1

• Identify the Business Requirements
• Visually model the Business Requirements

Part 2

• Translate the Business Requirements into CRM workflow processes
  • Initial CRM Planning
    • Create forms and fields
    • Identify triggers that start the CRM workflow process
  • Convert the Business Requirements into Dynamics CRM workflow processes that account for all possible cases
  • Identify duplicate processes
  • Identify CRM workflow process loops
  • Simplify CRM workflow processes

This post will be based upon a real world scenario and will be broken up into a two-part series.  In the first part, I will discuss identifying and modeling the business requirements.  In the second part, I will discuss translating the business requirements model into full-fledged CRM workflows.

Scenario

One of the business units in a company is working on a new venture with a series of manufacturers and needs to ensure that the manufacturers are being compliant.  They have placed auditors in distribution centers, but need a system to track/report on passed audits and the communications regarding compliance progress (or lack thereof.)  They intend to classify the manufacturers by status (red, yellow and green) to help determine which manufacturers are in compliance, and which might be troublesome.

Identify the Business Requirements

Identifying the business requirements is, in itself, no small task.  It requires the business unit to have a clear, definitive handle on their business process because, as most IT people realize (and business people sometimes don’t), IT systems do not do well with “fuzzy logic”.  This exercise can be accomplished with a good-old-fashioned “whiteboard session” or with a drawing application such as Microsoft Visio.  This may be an iterative process that requires multiple whiteboard sessions.  Having these sessions is good because it will help identify any fuzzy logic areas and force the business unit to make clear decisions on how the business process will flow.

Scenario Business Requirements:

• When a manufacturer passes three audits, they are considered compliant and will no longer be audited
• When a manufacturer passes an audit, the Customer Service Representative (CSR) should send an email notifying the manufacturer of a passed audit – after three passed audits, the CSR should notify the manufacturer that they are compliant
• After auditing begins, if a manufacturer has not passed an audit within 30 days, a CSR should call the manufacturer every five days regarding their compliance status, until they pass an audit – after a manufacturer begins passing audits, if they do not pass another audit within 30 days, the CSR should call the manufacturer every five days regarding their status, until they pass an audit
• If a manufacturer is not compliant within 30 days after auditing begins, their status should change from green to yellow – if a manufacturer is not compliant within 60 after auditing begins, the status should change to red

While Dynamics CRM can easily track interactions out of the box, everything else will have to be attained by creating a CRM workflow process.

Model the Business Requirements

After identifying the business requirements, model out the processes with workflows in mind, to ensure that you have correctly accounted for the logic.  The scenario can be broken down into three core processes: Passed Audit Notification Process, Status Update Process and the Auditing Progress Process. 

Passed Audit Notification Process

Status Update Process

Auditing Progress Process

When we put all three pieces together, the process looks something like this:

Manufacturer Audit Tracking Process

We now have a logical description of our business process.  As discussed earlier, in my next post I will delve into translating these business requirements into full-fledged CRM workflows.

Chris C. has been with ECI since 2010. Being a fully certified Microsoft Applications Consultant in Dynamics AX and Dynamics CRM, you will find him at the intersection of Business & Computing bridging the gaps between People, Technology and Business Processes.