Making Better Use of Business Process Flow Data

CRM 2013 Business Process Flows (BPF) have been designed to support a scenario where the same transactional records (opportunities, cases, custom entities like projects) can follow alternative process steps depending on the business logic required. For example, you can use the same opportunity entity to support the sales processes of two departments that are operating in very different markets and thus have different process stages as well as information content gathered within those stages.

You can either limit the availability of BPF’s by CRM security role, so that a salesman in department A will always get the sales process A for the opportunity records he creates, or you can enable the users to see a number of different processes and let them choose the correct one via the Switch Process button on the Command Bar. In the latter scenario the Select Business Process Flow dialog window will present the available processes, like this:

More processes will naturally mean more variety in the type of data your opportunity records will hold. Instead of a fixed number of stages in a specific order you’ll have opportunities that are following different sales processes with unique stages, which could easily lead to a situation where the CRM user may be comparing apples and oranges in the same entity view. How can we avoid such confusion in a multi-process environment? Hopefully this post will give you some ideas on the best strategy to manage your Business Process Flow data.

Working with the Stage Category

The officially recommended tool for making Business Process Flow stages visible in views and charts is the Stage Category option set. This is a field available on the Process Stage entity and you can select a value for it while editing the Business Process Flow process record.

Basically what this field allows you to do is to standardize the stage values across different BPF processes. You can enter a different name for the actual stage in the BPF editor but still link it to a Stage Category value that is used in some of your other processes, too. Depending on your business, there may be different sales processes that would each contain a conceptual Propose stage but apply different terminology for it. That’s one problem that the Stage Category can solve.

If you want to customize the list of values available for the Stage Category, just find the global option set under the Default Solution (Settings – Customizations – Customize the System) and update it like any other field. The new values will appear in he Business Process Flow editor after publishing the changes.

When building a view to display the opportunities by stage, you’ll need to add a column from the related Process Stage entity to leverage this information. In the Add Columns dialog of Advanced Find, choose the aforementioned entity and select the Stage Category field from the list that appears.

One limitation related to the view columns is that we can’t apply any sorting to the Process Stage field. That’s because it’s from a related entity and as a result it doesn’t appear as a possible field in the Configure Sort Order dialog. This means that our opportunity view can’t have the records nicely aligned per stage value, to simulate a pipeline, but instead we’ll need to rank them based on some field that’s directly available on the opportunity record itself.

Grouping or Filtering by Business Process Flow

So, we have the capability to merge stage values across different BPF’s into a single view. Pretty cool. Now, since different sales processes are often related to different types of product categories or business lines, what are the steps needed for creating an opportunity view that also displays the name of the BPF process chosen for the record? For example, if we want to group the revenue per process instead of process stage, which field do we need to add into the view?

Sorry, there is no such field. Thank you, have a nice day.

Excuse me, what?! Didn’t you just show how to harmonize the stage values across different processes? Surely there’s a way to un-harmonize things and break it down based on individual processes and stages?

Well, stages yes, but processes, no. You see, there isn’t a direct relationship to the actual Business Process Flow process entity from the opportunity entity (or any other BPF enabled entity). While the system does store a GUID reference to the process and process stage records in the StageId and ProcessId fields, these are “unique identifier” type of fields that you can’t reference in Advanced Find query criteria. We could add them as a view column, but they’d just be gibberish like “3e8ebee6-a2bc-4451-9c5f-b146b085413a”.

The Process Stage entity that we examined earlier is a parent entity of the opportunity and it can be accessed in Advanced Find, but it doesn’t contain any field that would specify the name of the process to which the stage belongs to. When selecting view columns in Advanced Find we can only go one level up, but luckily when building a filter criteria for the view we can query entities further away. This means we can reach the Process entity related to the Process Stage entity and find our Alternative Sales Process from there, as illustrated below. (Note that you’ll need to change the default lookup view to display the BPF processes, as otherwise you’ll only see workflow processes to choose from.)

By adding this criteria we are able to build a view containing only opportunities from a specific Business Process Flow. To see the total pipeline revenue per each process we’d just need to switch between the views, or build a dashboard that contains one list/chart per process. Not quite as elegant as having a single chart grouping the revenue per process, but it’s still better than a mixed bucket of opportunities from all over the place.

What if I told you there was a better way to do this than the out-of-the-box data model provides? Would you be interested in seeing its possibilities? Then you’re in luck, because that’s what I was going to write about next.

Caching the Process Values in Custom Fields

Business Process Flow is a nice addition to Dynamics CRM, but long before we had these flashy graphics of process stages visualized on the form, we had the tireless background workers called workflow processes. Since BPF is more of a process map that tells the user what to do, rather than a process automation feature, you’ll quite often end up using workflows in conjunction with the visual BPF components to build your business processes in CRM.

Many of our problems listed earlier would be solved if only we had the Process and Process Stage fields available directly on the opportunity form, instead of them only being represented via the BPF control. So, why don’t we add them there? It’s only a matter of adding two custom fields on the opportunity form, after all. Let’s call these text fields “Process Name” and “Process Stage Name”.

New blank fields aren’t much good on their own, so next we’ll have to figure out a way to get them populated with the values we want. We already know workflow is out tool of choice, but how should we configure it if we want to always reflect the latest Business Process Flow process and stage values on the record itself?

Whenever a record is created and a BPF is associated with it or the stage in the process changes, CRM will update those unique identifier fields we saw earlier. Since we want to capture not only the process change but also stage changes, our logical choice will be to set our workflow to run on record create and the Process Stage field change events.

The only thing we need to perform in the workflow is a single update step on the opportunity record. I’ve added a new form section called “Process” to hold the Process Name and Process Stage Name fields, but these could also be hidden fields if required. We’ll populate them with values from the related Process Stage entity. While the parent Process name wasn’t a field available on Advanced Find, here we’re free to select it and input the value onto our custom Process Name field on the opportunity. Repeat the same action for the Process Stage field.

Now we can run this workflow for all the existing open opportunities to update the name fields. Any new opportunity created or updated will immediately pick up the values into the Name fields, thanks to the real-time nature of the workflow. If we now go and build views and charts for showing the sales opportunity data, we’ve also got the Sales Process available as a field by which we can sort the view data and group records in a chart. The same naturally goes for the Sales Stage field, too.

The one caveat to be aware of in this approach is that the field labels will not be language specific. If you share a sales process across many different regions of your business, then the charts and views will still reflect the base language value.

Beyond Views & Charts

There’s one other reason why it makes sense to replicate the process and process stage values onto the record to which the Business Process Flow is related to. If you’ve experimented with the new Business Rules feature in CRM 2013 then you may have come across one limitation that they have in their current form: you can only reference fields from the current entity. This means that you can’t build a rule that would change the visibility or requirement level of a form field based on a value that’s stored on a related record, such as Process Stage.

Well, thanks to the nifty lil’ workflow that we just built, that limitation is history! In case you want to control which form fields are presented on the opportunity form in each stage of the sales process, all you need to do is use the new custom field for Sales Stage Name that we just created on the opportunity entity. Since our workflow rule is run in real time, the value will be available to the Business Rule condition the moment the stage changes and the form is refreshed. For example, if we wanted to not show the Proposed Solution field while we’re in the Qualify stage of the sales process, all we need to do is build a rule like this:

Additionally we’d have to create another Business Rule to un-hide the field after we move away from the Qualify stage, since Business Rules really are just form Javascript generated via a GUI.

Anyway, the amount of configuration options you gain from caching the process and stage values onto the transactional record itself are so significant that I find it difficult to find a reason why you would not want to do it. With a tiny addition to the default data model and a simple workflow process you can take your sales process automation and reporting to another level in Dynamics CRM.