Skip to main content

A closer look at the Dynamics CRM Process Control

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:

(click on the animation to see the full-size version)

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?
We should know more over the next three or four months as Orion is rolled out.

Comments

Popular posts from this blog

Copying data to Salesforce Sandboxes using TalenD

A common problem with Salesforce Developer Sandboxes is that they are blank. Really you're going to want some data in there, so there are various strategies for copying data from your live instance to the Sandbox. There are some paid-for solutions - SFXOrgData , Salesforce Partial Data Sandboxes - but if you've got a decent ETL tool you can build your own. There are a bunch of free ETL tools for Salesforce: JitterBit Data Loader is good for quick ad-hoc tasks but the free version makes it difficult to manage specific ETL projects or share projects with other users Pentaho Community Edition - an open source edition of the enterprise version Apatar was a free open source Salesforce ETL which still works but development seems to have stopped since 2011 TalenD Open Studio is an open source ETL tool For the task of copying data from live to a Sandbox, either Pentaho or TalenD Open Studio could be used, depending on preference. Here's a good comparison of the dif

SSRS multi-value parameters with less fail

SSRS supports multi-value parameters, which is nice, but there are a few issues with them. This is how I deal with them. Two of the problems with SSRS multi-value parameters are: You have to jump through a few hoops to get them to work with stored procedures The (Select All) option, as shown above The reason the (Select All) option is a problem is that it is a really inelegant way of saying 'this parameter does not matter to me'. If you have a list with hundreds of values, passing all of them as a default option just seems wrong. Also, if your report shows the user which items they selected, printing the whole list when they choose (Select All) is excessive. So in this post I'm going to show my particular way of: Jumping through the hoops to get Multi-Value params in a stored procedure Adding a single '--All--' value that the report interprets as meaning all the options. Getting Multi-Value params to work with Stored Procedures This is

Remote Desktop on High DPI screens

Scott Hanselman wrote a nice blog post back in January about some of the issues you might face running Windows on a High DPI screen like that of a Surface Pro or Lenova Yoga. I'm kindof mystified that he didn't mention Remote Desktop though because thats been the number one problem for me on High DPI screens. That said, if you remote into very recent Server OS's like Windows Server 2012 R2, then apparently Remote Desktop will sort out the DPI scaling automatically. Perhaps Scott hadn't noticed the Remote Desktop issue because he only remotes into Server 2012 R2. Certainly if I was Scott, I wouldn't remote into anything less than that. But, in practice, I regularly have to remote into Server 2008 machines and yes even Server 2003. If you do that from a high DPI screen, the remote desktop is rendered at regular pixel size, which makes everything tiny. Its hard to show screenshots of High DPI screens that correctly convey the pixel size, so I've photoshoppe