The NDA is off, and the next version of Dynamics CRM is due in the next couple of months. Its official name is Dynamics CRM 2013, but if we named software the way we do movie sequels, I’d recommend “Dynamics CRM 5: The Process Edition”. Yes, I know the new flow UI is getting all the attention, but for my money, business process enhancements are the biggest and most important new feature area.
The term business process is so generic-sounding it’s easy to miss its important meaning in Dynamics CRM speak: it refers to a category of customization techniques that allow you to implement processes in CRM. To understand the evolution of the terminology (and more importantly, the functionality), let’s take a little spin down CRM memory lane:
In Dynamics CRM 4.0 and prior versions, we had a single kind of business process. We called them workflow processes, and we knew that they were background processes that ran asynchronously, could be triggered by events or manually, and did not support user interaction as they ran.
Dynamics CRM 2011 added dialog processes to the business process mix, and dialogs are everything workflows are not: they run synchronously, require user input to start, and feature a wizard-like forms experience that must be run from start to finish. This necessitated a formal designation of the term business process as referring to a category of things. So we can say that CRM 2011 contained two specific types of business processes: dialogs and workflows.
Now comes Dynamics CRM 2013, with two brand new types of business processes (actions, and business process flows, and at least one very significant enhancement to an existing type (real-time workflows). Hence the need for an article like this one. (That is: I needed to write the article, just so I could figure it all out.)
The following figure provides an illustration:
As in previous versions, when you create a new business process you must specify the category. In CRM 2013, Action and Business Process Flow are the new options. (Real time workflows are specified within the designer, when you’re building a workflow process. You’ll see that below.)
Two more background points before walking through the new business process features:
Business processes are for business users. They are one of several ways you can extend and customize Dynamics CRM. The platform supports many other customization techniques (custom fields, entities, relationships, Jscript for form events, plugins) which are typically performed only by developers or administrators. Business processes are different, in that they are intended to be built by people who are not developers. Developers can certainly extend business processes, and interact with them programmatically, but you don’t need to be a developer to build the business processes this article’s about.
Business processes are different from business rules. This is another terminology issue: business processes are different from business rules. Business rules -- yet another new customization technique in CRM 2013 – give us a no-code way to implement dynamic form behavior, and with certain limitations can be used as an alternative to Jscript. So you can think of these as another delegation of customization capabilities to non-technical users…but don’t confuse them with business processes. (For more information, here’s an article I wrote recently on Introducing CRM 2013 Business Rules.)
Now that we’ve got the context and terminology, let’s see what cool new stuff Dynamics CRM 2013 has to offer in the way of business processes.
Business Process Flows
Business Process Flows are a new type of process in Dynamics CRM 2013. They provide a visual presentation of a process, in a special area at the top of a form that displays the stages of the process as headings across the top, and within each stage information that should be provided before proceeding to the next stage.
For example, the following figure shows the default CRM 2013 lead form, with the process flow area highlighted.
For a user, it’s visually obvious what needs to be done at each stage, and after the information is provided the user manually advances the process to the next stage by clicking the Next Stage button on the ribbon.
One of the most interesting thing about business process flows is that they can span multiple record types. Take another look at the lead form in the previous figure. It’s not obvious the first time you see it, but everything past the Qualify stage of this 4-stage process happens on the Opportunity form!
Suppose you qualified the lead, using the built-in button at the top of the form. The next thing you’d see is the following figure:
Quick: can you tell the difference? You’d have to be looking pretty closely, which I suppose is the point. Business process flows effectively make the process more important than the record type.
The authoring experience is pretty simple. For example, if you clicked the MORE COMMANDS (…) menu on the opportunity form, you could select Edit Process from the menu you see here:
I’ll save a detailed treatment of the authoring process for another article; for now, take my word for it: it’s easy.
One of the reasons it’s easy is that business process flows really don’t do very much. They don’t create or assign records, they don’t have conditional logic. Basically, they let a non-technical user associate fields (referred to as “Steps” in the process designer) with a stage, so that they show up prominently in the process area at the top of the form. For example, consider the following figure which zeroes in on the process area for the Propose stage of this (slightly customized) process:
Identify Sales Team, Develop Proposal, Complete Internal Review and Present Proposal are just fields on the opportunity entity, and the process flow designer gives a non-technical user an easy way of making them prominent and associating them with a stage. This red asterisks in the figure illustrate one more somewhat subtle benefit of process flows: the ability to require fields at a specific stage of a process. This would have required code in the previous version, and now in CRM 2013 we have two no-code ways of doing it (the other being business rules).
I mentioned above that business processes are intended to be authored by non-technical users. The default security roles in Dynamics CRM 2013 reflect this intention: all of the manager roles (name contains “Manager”) and anything above have permissions to activate one of these business process flows.
I like business process flows, and I think organizations will get plenty of value from them. This is all still new, and I won’t claim to have it fully groked yet. But I’m not as pumped about business process flows as I am about some of the other new business process features (e.g., the next topic), and I think the reason is that they don’t seem to solve problems I encounter very often. For now, I put business process flows into the new feature category of Hats off to the product team for coming up with this totally brand new approach that none of us really knew we needed, but that will probably turn out to be indispensable and end up making me look foolish for not immediately appreciating its utility.
These things, on the other hand, get me all fired up since they solve problems I do encounter every day. Real-time workflows – just as it sounds they should – run in real time. To appreciate the significance of this, it helps to have some experience with workflow processes in previous versions, which always ran “asynchronously”, i.e., not in real time. One of the drawbacks of this was the user experience: typically 15-30 seconds elapsed between the triggering action and the visible result. What this meant was that workflows weren’t really suitable for functionality requiring a snappy UI.
But that all changes with real-time workflows. Referring to the following figure, let’s take a look at a simple example that illustrates how useful these things will be.
This is a screenshot of a slightly customized opportunity form, and let’s suppose it describes three requirements our business users have come up with:
When a user selects a value in the Account lookup field, information from the account record should display in the Account Information section. (The fields in this section are custom, and they map to corresponding fields on the account record. If you always created opportunities from the context of the account/customer form, you could accomplish the same thing with custom field mappings. But the workflow approach covered here allows you to get these fields filled in when the opportunity is created “from scratch” – a pretty common situation.)
The Weighted Revenue field should display the product of Est. Revenue and Probability.
Rather than being entered manually, the Topic field should be auto-filled, using the Opportunity Type and the Account fields to implement a standardized naming convention for our opportunity records.
Requirements like these could be satisfied using workflow processes in previous versions…but not very well, since the lag time characteristic of async workflows doesn’t really work for things that users want to happen in real time.
But a real-time workflow can do this job nicely. When you create a new workflow process, you can specify that it should run in real time by de-selecting the (recommended) Run this workflow in the background option:
In the designer, a real-time workflow looks pretty similar to what we’re used to from previous versions, but with a couple of differences. Here’s the Process Properties section for this process:
First, notice you can convert a real-time workflow to a background workflow, and vice versa. This isn’t one of those places where you can’t change your mind.
Second, notice the “Before” and “After” options on the Start when triggers. This workflow is triggered when a new opportunity is created and when certain fields change, so we don’t have any options. But workflows triggered by status changes and deletes do have the option of running before or after the operation. This is another important advantage of real-time workflows, but I’ll save that topic for another article.
Anyway, so we’ve got a real-time workflow. What does it do? I’ll collapse the properties section to show you the workflow steps:
This will look familiar if you have some experience with CRM 2011 workflows, since it’s essentially unchanged. The Update step fills in the fields in the Account Information section, pulling them from the Account record, which is a parent of the opportunity. Next, notice the standard 3-step to calculate the weighted revenue field. Dynamic values in the workflow designer work the same as they did in previous versions, which means you don’t really have a calculated field capability.
Real-time workflows are similar in functionality to plug-ins, with the obvious difference that you don’t need to be a .NET developer to take advantage of them. One thing you’ll notice about them is that the user experience is slightly different from form script (Jscript) and business rules:
With a real-time workflow, you see the results as soon as the record is saved. In this example, if you change any of the “independent” values (say, est. revenue or probability), the “dependent” value (weighted revenue) is updated in real time…once the record is saved. In Dynamics CRM 2013 form changes are automatically saved about every 30 seconds. OR, they can be saved at any time by clicking the save button at the bottom right of the form.
With Jscript or business rules, calculations are performed as soon as field values are changed.
This alternative user experiences reflect an underlying difference: workflows and plug-ins are triggered by database events; form script and business rules are triggered by client-side events. If you’re new to this, it would be worth working through a direct comparison of the two approaches: the example in my Business Rules article does the identical “weighted revenue” calculation with the (client-side) business rules approach. The real-time workflow approach presented here is the server-side alternative.
Continuing our tour of business process newness in Dynamics CRM 2013, we come now to Actions, another one of those generic-sounding words that masks the importance of the new functionality. Actions are similar to workflows in that you use the workflow designer to create them: so they can be built by non-technical users to implement business logic and processes.
But they have several differences from traditional workflows:
They can take input and output arguments.
They are not tied directly to entities: while you can specify an entity as in a regular workflow, you can also create a global action.
Finally, they can only be accessed via code: so you need a developer to write a plugin or a custom workflow to put them to use.
That last point is especially important, as it introduces a caveat to the guidance that “business processes are for business users”. The development scenario with actions is that the business user can implement the business logic, and modify it as necessary, but that the developer writes code to hook up the action to system events, passes in the right arguments and so forth.
Here are some of the most common ways actions will need to be invoked for now:
From a custom application, or an integration with another application that communicates with CRM via web services.
From code within a plugin or custom workflow.
From Jscript code, behind a form, a custom button or some other command.
Because it can take arguments and does not have to be tied to a specific entity, an Action is created at a higher level of abstraction than a traditional workflow process. For example, database developers typically think in entity-specific verbs like Create, Read, Update, and Delete. But with actions, a business user can think in terms of business verbs like “Route”, “Assign”, “Escalate”, or “Onboard New Client”.
Let’s take a look at how you might use a custom action. The following figure shows the Process Arguments section, probably the most distinctive characteristic of the action design experience:
In this example, I’m building an action that creates case records based on information from an ERP application: when an accounts receivable goes past due we want to automatically create a corresponding case in Dynamics CRM, associating it with a customer, giving it appropriate values for “Type” and “Category”, and recording the past due amount and the date it was due.
The business user knows what kind of data is needed by the account managers to work these overdue accounts; that’s reflected in the input arguments in the previous figure.
The business user also knows how these data will drive the collections process, and a simple example of that is shown in the following figure:
Here you can see the familiar step editor – identical to what we have in CRM 2011, except for a couple of things actions don’t have. (They can’t have Wait conditions, for example.)
The business user has the knowledge required to build the collections process, but certainly doesn’t know how to build an application that integrates Dynamics CRM with an ERP. Which is the whole point: the developer can provide the plumbing, and as long as the right arguments get passed in, the business process can do what it needs to, be modified as business changes and so forth.
So Many Options!
Business process flows, real-time workflows and actions are all important additions to our no-code customization toolkit. And as we’ve seen, even though business rules aren’t considered a process, per se, you can sometimes use them as an alternative way to accomplish the same thing. It’s great to have all of these new options, and I know we’ll all be discovering great applications for them in the coming weeks and months!