Microsoft Lystavlen - the Online display board

Lystavlen is the danish word for 'the display board'. This blog is all about sharing the beauty of Office 365 and CRM Online.

CRM 2013: Understanding Processes

CRM 2013: Understanding Processes

  • Comments 7
  • Likes

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

Details:

  • Assign Record: You can assign the record that the workflow is running on, any of the records linked to that record with an N:1 relationship, or any records created by earlier steps.
  • Assign Value: Sets a value to a variable or output parameter within the process.
  • Change Status:  Changes the status of the record that the process is running on, any of the records linked to that record with an N:1 relationship, or any records created by earlier steps.
  • Check Condition: A logical "if-<condition> then" statement. You can check values for the record that the workflow is running on, any of the records linked to that record in an N:1 relationships, or any records created by earlier steps. Based on these values you can define additional steps when the condition is true.
  • Conditional Branch: A logical "else-if-then" statement, the editor uses the text “Otherwise, if <condition> then:”. Select a check condition you have previously defined and you can add a conditional branch to define additional steps when the check condition returns false.
  • Create Record: Creates a new record for an entity you choose and assigns values you choose to attributes.
  • Custom Step:  Provides extensions to the logical elements available by default in Microsoft Dynamics CRM. Steps can include conditions, actions, other steps, or a combination of these elements. Developers can create custom workflow steps. There are no custom steps available in Microsoft Dynamics CRM by default.
  • Default Action:  A logical "else" statement. the editor uses the text “Otherwise:”. Select a check condition, conditional branch, wait condition, or parallel wait branch that you have previously defined and you can use a default action to define steps for all cases that do not match the criteria defined in condition or branch elements.
  • Link Child Dialog: Starts a Dialog process that has been configured as a child dialog.
  • Page: A container for Prompt and Response steps in a dialog.
  • Parallel Wait Branch: Defines an alternative wait condition for a background workflow with a corresponding set of additional steps that are performed only when the initial criterion is met. You can use parallel wait branches to create time limits in your workflow logic. They help prevent the workflow from waiting indefinitely until the criteria defined in a wait condition have been met.
  • Prompt and Response: Displays a prompt within a dialog page and may provide a field to capture data from a response.
  • Query CRM Data: Defines a query that returns data to provide options for a response in a Prompt and Response step of a dialog.
  • Send Email: Sends an email. You can choose to create a new email message or use an email template configured for the entity of the record that the workflow is running on or any entities that have an N:1 relationship with the entity, or the entity for any records created by earlier steps.
  • Stage: Stages make the workflow logic easier to read, and explain the workflow logic. However, stages do not affect the logic or behavior of workflows. If a process has stages, all the steps within the process must be contained with a stage.
  • Start Child Workflow: Starts a workflow process that has been configured as a child workflow.
  • Stop Workflow/Stop Dialog:  Stops the current workflow, dialog or action. You can set a status of either Succeeded or Cancelled and specify a status message.
  • Update Record: You can update the record that the workflow is running on, any of the records linked to that record in an N:1 relationships, or any records created by earlier steps.
  • Wait Condition: Enables a background workflow to pause itself until the criteria defined by the condition have been met. The workflow starts again automatically when the criteria in the wait condition have been met.

 

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

  • reduce need for training because new users don’t have to focus on which entity they should be using, they can let the process guide them
  • be configured to support common sales methodologies that can help sales groups achieve better results
  • help new service staff get up-to-speed more quickly and avoid mistakes which could result in dissatisfied customers

The main principle behind business process flows is to guide you to achieve specific goals and help you understand the following:

  1. Where am I?
  2. What do I do next?
  3. Where did I come from?

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.

 

See also

  • Business Processes in Microsoft Dynamics CRM 2013 (by Richard Knudson) - link
Comments
  • 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.

  • Great

  • Hi Jesper

    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...

    Kind regards,

    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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment