Freigeben über

CRM 2013: Understanding Processes

  • Artikel

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

  • Anonymous
    January 01, 2003
    thank you

  • Anonymous
    October 01, 2013
    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.

  • Anonymous
    October 03, 2013
    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.

  • Anonymous
    October 03, 2013
    Great

  • Anonymous
    October 28, 2013
    The comment has been removed

  • Anonymous
    December 04, 2013
    Can we set a security role for a step? ie. Approval can only be given by the CEO not any other user

  • Anonymous
    February 25, 2014
    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.