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:
- Identify the Business Requirements
- Visually model the Business Requirements
- 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.
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.