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. (more…)
Given how much time I’ve spent wondering “how should I do this” when it comes to CRM workflows, the wording of this blog post’s title is pretty bold. Is there really a single right way to build reminder workflows and do I know nearly enough about them to claim the privilege of defining the proper design pattern for them? This is actually just more of a provocation through which I’m hoping to gather feedback on the inevitable shortcomings of this post via the comments section. Another reason behind this choice of the title is that I stand on the shoulders of giants when it comes to my knowledge about CRM workflows, meaning everything I know about them I’ve read from blogs elsewhere and I’ll try my best to highlight the articles deserving most attention via linking to them as we move forward.
Since it’s quite a common phase in the lifecycle of a Dynamics CRM organization to sooner or later face a situation where you want to clean up the system from legacy data structures that no longer serve their purpose, I want to highlight a couple of tools that will help you on this journey towards a better organized CRM system.
