The usefulness of Checklists
If you use standard 'flowchart' notation to describe how to make a cup of tea, you'll get something very linear, like this:
A lot of space in a standard flowchart is taken up describing what order things should happen in. But actually, for some of the steps, the order is not that important. We certainly have to wait for kettle to boil before pouring the water into the mug, but the order in which we add milk and sugar doesn't matter. If we re-draw the process using a notation that allows for certain steps to happen in any order, we get something like this:
If you look at real world business processes, you'll probably find the same thing: although there are certain steps that do have to be ordered, a lot of them can be split into 'stages' and then tackled in any order. In many cases a series of checklists is a much better model for business processes than a classic flowchart.
The CRM Process Control
Someone at Microsoft must have noticed this too, because the new CRM Process Control is all about modelling processes as a series of checklists.
The Process Control is the centrepiece of a major overhaul to the Dynamics CRM UI that I wrote about previously. It was originally released in December 2012 update (aka 'Polaris') and is being further enhanced in the upcoming Dynamics CRM 2013 release (aka 'Orion'). It looks like this:
... and its key features are:
- Each tab in the Process Control is a 'Stage'. Within a stage is a number of Steps
- As you click on each Step, you are asked to do something. Generally there are three types of Step:
- Fill in a field - a panel will appear with the appropriate control (textbox, dropdown, datepicker or whatever) to let you fill it in
- Tick off an item - more basic, just clicking on the Step marks it as 'done'
- Special Steps - there are some steps that do quite specific things, e.g. the 'Similar Cases' step on the Case process reveals a large panel that lets you search through other cases to help find a solution to the current one.
- A process can span more than one entity - in the current version of CRM (Polaris), the 'sales' process starts on Lead and then moves the user to Opportunity on the second stage.
Different Types of Step
Field Steps
Many (but not all) steps correspond to a field on an entity. They render differently depending on the type of field. Here's an animation of the main field types and what their Steps look like:
Note that for Lookup fields, initially the Process Control suggests a few matches based on the text entered, but there is also an option to 'Look Up More Records' which brings up a more comprehensive search panel.
In the 'Process Control Customization Tool', to add a field-related steps, you simply add the step and select the field:
The convention seems to be that if a field appears in a Process Flow, you probably don't put it on the main form as well. The idea presumably is to simplify forms and only show the user fields relevant to the current stage. You can of course still put the field on the main form if you want. However (in Polaris at least) updating the field in one place will not automatically update it in the other. For example if 'Estimated Budget' appears on the Process Control and on the main form, if you fill it in on the form you'll have to refresh the screen before it also shows on the Process Control, and vice-versa.
Special Steps
Not all Steps correspond directly to a field. In the 'Polaris' version of the Customization Tool, certain entities give you a special drop-down at the top of the tool for selecting special steps:
The special steps available in Polaris are "Find Customer", "Find Case", "Similar Cases" and "Resolve Case".
The "Find Customer" and "Find Case" steps allow the user to perform a search, but they also have a 'New' button that displays a Quick Create panel that allows the user to create a new record directly:
The "Similar Cases" step is very specific - it brings up a large panel that allows the user to search cases and also displays posts and activities for those cases:
The existence of such a specific step suggests that (maybe) it will be possible to define arbitrary custom steps for the Process Control that can display arbitrary panels (perhaps defined via FormXml). I haven't seen any announcements about this, so perhaps it wont be possible for a while yet. But fingers crossed.
The "Resolve Case" step does not have any special UI behaviour but it does set the state of the Case to Resolved. Again, this suggests that it might be possible in future to tie arbitrary bits of processing to Steps. But again, I'm not aware of any announcements so far.
'Mark Complete' Steps
Several of the built in processes in Polaris have 'tick off' steps that appear as 'mark complete'. When you click on them, they change to 'complete':
This is done via an innovative use (or 'hack') of the TwoOptions field type. The Two Options are defined as 'mark complete' and 'complete', with 'mark complete' set as the default:
This makes it look nice and tidy on the Process Control - you get a nice bit of text saying 'mark complete' - but looking at the data model as a whole I'm not sure its a very good idea. Taken away from the context of the Process Control, the 'mark complete' option could be very confusing. For example, imagine a Report or Advanced Find that is displaying a list of Opportunities. The 'Send Thank You Note' column would be full of 'mark complete' and 'complete' labels, and it wont be entirely clear that 'mark complete' actually means 'this has not been done yet'.
Improvements in Orion
The upcoming Orion release (Dynamics CRM 2013) is going to bring a number of changes and improvements to Process Flows and the Process Control.
(This screenshot taken from Reuben Krippner's recent presentation at WPC2013)
- There are some slight style changes, such as the Process Control being collapsible, and the current stage being highlighted by a little blue flag (see screenshot above)
- It will be possible to mark certain steps as mandatory - they must be completed before moving on to the next stage
- It will be possible to define process flows for any entity including custom entities
- It will be possible to have multiple process flows for an entity. For any given record, the user can then choose which process flow to use (via a 'Select Business Process Flow' dialog)
- Process Flows will be able to span multiple entities - this was already shown in Polaris with the Sales process flow that spanned Lead and Opportunity. However in Orion this will be expanded and presumably apply to custom entities as well
Questions
So, the concept of a series of checklists is a good one, and in the new Dynamics CRM UI, Microsoft have found a way to implement it in a simple but flexible way.
As a developer, I'm left wondering about the following:
- Will it be possible to define arbitrary UI panels that relate to Steps? (like the 'Find Similar Cases' step)
- Will it be possible to define arbitrary bits of processing for Steps? (like the 'Resolve Case' step)
- What 'state' is associated with a Process Flow? Most of it seems to be based on the fields in the underlying record and whether they are filled in or not, which suggests that Process Flows in themselves are largely stateless. But does CRM keep track of which 'stage' is current, and if so, where does it track that?
- If there is 'state' relating to Process Flows, will it be possible to manipulate that state via the API - for example set which Stage a record is on, or set which Process Flow a record is connected to?
Comments