In Microsoft CRM you can define and enforce consistent business processes. Consistent processes helps you focus on your work and not on remembering to perform a set of manual steps.
Processes can be simple or complex and they should be expected to change over time. Microsoft CRM provides several options to define your processes. Its important to understand how you can use each type to get the results you need.
Processes are designed to be used by people who are not developers. The rules defined within processes contain similar logic that a developer may apply using code, but you don’t need to call in a developer each time you want to change the rules. However, you do need to have a clear understanding of the logic in the rules you want to apply and understand the capabilities of each type of process.
There are four categories of processes you can utilize in CRM 2013:
Workflows Automate business processes behind the scenes. Workflows are typically initiated by system events so the user does not need to be aware that they are running, but they can also be configured for people to manually initiate them. Workflows can operate in the background (asynchronously) or in real-time (synchronously). These are referred to separately as background workflows or real-time workflows.
Dialogs Create a user interface that will guide people through a script for customer interaction or a wizard to perform complex actions consistently.
Actions Expand the vocabulary available for developers to express business processes. With core verbs like Create, Update, Delete, and Assign provided by the system, an Action uses those core verbs to create more expressive verbs like Approve, Escalate, Route, or Schedule. If the definition of a business process changes, someone who is not a developer can edit the Action so the code does not need to be changed.
Business Process Flows Use Business process flows to define the steps in which people should enter data to achieve an outcome. Business process flows add a control to the top of a form that will show people what data they need to enter in order to move forward to the next stage and ultimately to completion of a business process. A business process flow can span multiple entities.
Comparing Workflows, Dialogs and Actions
Processes other than business process flows can check conditions, apply branching logic and perform actions. They perform these actions in a series of steps. Business Process Flows contain stages and control advancement to stages, but they do not provide any of the other capabilities. The following table compares the available steps in Workflow, Dialog, and Action processes (see details for each row below the table):
Orange = Background Workflow Only
Business Process Flows
In CRM 2013, a process-driven approach of solving problems is being advocated, where processes act as proactive elements in the system that guide users about the next steps and help navigate different flows to achieve a desired outcome.
At the top of updated forms you can see a process flow control that provides a guide for you to get your work done.
The process flow control provides a streamlined experience that ties data entry with stages in the lifecycle of the record.
Business process flows provide a streamlined user experience that leads you through the processes your organization has defined for interactions that need to be advanced to a conclusion of some kind. This user experience can be tailored so that people with different security roles can have an experience that best suits the work they do.
Business process flows can
The main principle behind business process flows is to guide you to achieve specific goals and help you understand the following:
Single or Multiple Entities
A business process flow in CRM 2013 can be used for a single entity or span multiple entities. For example, you may have a process that begins with an Opportunity, then continues to a Quote, an Order, and then an Invoice before finally returning to close the Opportunity.
Stages and Steps
With Business process flows you define a set of Stages and Steps which are then displayed in a control at the top of the form. Each Stage contains a group of steps. Each step represents a field where data can be entered. You can advance to the next stage using the Next Stage button. You can also make a step required so that users must enter data for the corresponding field before they can proceed to the next stage. This is commonly called ‘stage-gating’.
Security Roles and Switching Processes
You can associate business process flows with security roles so that only people with those security roles can see or use them. You can also order the business process flows so that you can control which business process flow will be set by default. This works in the same way that multiple forms for an entity are defined.
When someone creates a new entity record, the list of available activated business process flows is compared to the business processes flows that the person’s security role will show them. The first activated business process flow in that list is the one that will be applied by default. If more than one active business process flow is available you can chose Switch Process from the command bar to apply a different process. Whenever someone switches processes, the current process stage will be set to the first stage of the newly applied business process flow.
I hope you get a picture of the breadth and depth of the process support in CRM 2013, and how it can be applied to help you focus on your work.
Nice Summary, now if only Microsoft can deliver a visual tool that allows you to build processes as the current model is a bit beyond most customers.
Jesper, great document. I do think that designers will now face some tricky decisions as to which process route to follow when building CRM solutions. I can see certain scenarios where different types of processes and plug-ins could conflict where process design decisions are not as well thought through as they should be.
I agreed, it is indeed a very nice summary of business processes and other processes.
I am however a bit surprised about some of the limitations of business processes i CRM 2013 and I'm hoping that you might be able to shed some light on whether any of these limitations and concerns will be addressed in a future rollup / release, ie. what is planned for the roadmap of business processes in CRM 2013?
1) You can only have one running business process per entity instance.
Most companies will have a need for a lot more than a single simultaneous business process flow for their key entities like contact and account, on which all other data is linked. For example a case worker and a membership employee (with completely different non-overlapping responsibilities) and very different business processes (ie. tasks they need to complete) locked to their specific roles, will be competing for access to execute their business flow on a key entity instance (shared between the two roles).
Neither dialogs or workflows exhibit this kind of limitation, which for me is a big disappointment about business processes in CRM 2013.
2) Business processes are purely sequential, no conditional logic is supported.
You can build some custom conditional logic using plugins and custom workflow activities, but business processes remain sequential, there is no kind of branching logic, unless you "cheat" and switch processes using a custom plugin.
3) It is not possible to close a business process flow and reclaim the visual real estate, it can only be minimized.
I don't quite understand why business processes are not started on-demand for the individual instance and why it is not possible to close the business process, once completed - it can only be minimized.
Also, why aren't stages available upon record creation? You have to save the new record - which is probably going to share all required fields with the stage steps for that record - before stages are rendered...
Erik K. Aarslew-Jensen
Can we set a security role for a step?
ie. Approval can only be given by the CEO not any other user
Andrew - you could achieve that by creating an approval field with field level security enabled, and assigning a field security profile with the permission of "read" to everyone, and only "edit and create" to the CEO. Everyone will be able to see it, but only the CEO change it. Make it default to null/empty and a required field within the stage, and you have your approval process.