Building Business Processes in Dynamics CRM 2011: Installment 3

Actions and Conditions in Dialogs

June 25, 2011 Dialogs have most of the same actions and conditions as workflows, and a few more besides. In this article I focus on “the things dialogs can do that workflows cannot” with an emphasis on frequently encountered requirements such as conditionally branching between dialog pages. We start with a side-by-side comparison of what dialog and workflow processes can do, courtesy of the Add Step drop-down in the process Step Editor. The highlighted options are the ones each can do that the other cannot. This article is an excerpt from my upcoming book, Building
Business Processes in Dynamics CRM 2011. All articles in the series:
Add Step for Dialogs
 Add Step for Workflows

As you can see, dialogs do not have wait conditions and workflows do. This is because dialogs require user input from start to finish, so wait conditions of the type workflows have (wait until one month before a subscription expires and send a reminder e-mail, etc.) would not work very well for dialogs.

So excepting wait conditions, we can say that dialogs can do everything that workflows can do, plus the following:

  • As we’ve seen, the Page and Prompt and Response constructs present the user experience. Prompt and Response will be grayed out on the menu if the cursor is not inside a page.
  • Dialogs can Query CRM Data. As was mentioned briefly above, this is an important capability and lets you present users with queries of CRM data as drop-downs from which they can select a value. This will be covered in detail in the next section.
  • Dialogs also have an Assign Value action. This is used to update values in variables as a dialog runs. The Variable construct is also unique to dialogs, and will be discussed in detail later in the book.
  • The Link Child Dialog action is similar to a workflow’s ability to start a child workflow, except that a parent dialog can pass values (Input Value, in the Step Editor) to a child dialog. This also will be discussed in detail later in the book.

Working with Conditions in Dialogs

Apart from not having a Wait Condition, conditional logic works the same in dialogs as it does in workflow processes. That was covered previously, so here the focus will be on conditional logic specific to dialogs.

Conditionally Branching to Pages

One of the scenarios you will often encounter is the requirement to conditionally branch to a page based on a user’s response. Suppose, in the Create Case for Account dialog discussed previously, you wanted to prompt the user for the customer’s satisfaction level, and for dissatisfied customers, prompt the user for some extra information. Here’s the logic we want to capture in the dialog process:

The following two figures show how to build a dialog like this one. The first one shows the first page, which has several Prompt and Response pairs, including the last one, which instructs the service representative to gauge the customer’s satisfaction level:

The rest of the dialog comes in three main parts. The first one creates the case record based on the gathered information. The second part (highlighted) starts with a Check Condition: if the customer is dissatisfied, we branch to the dialog’s second page, which prompts for whether to escalate the case by routing it to a special queue.

Specifying Conditions for Dialog Processes

In the Step Editor, conditional logic always has a structure similar to this:

If you follow the instructions and click the <condition> (click to configure) link, the Specify Condition dialog appears. In general, the way you specify conditions is similar for dialogs and workflows, but there are some important new options specially designed for use in dialogs. Let’s have a brief review of how to use the Specify Conditions dialog, with an emphasis on what’s new for Dynamics CRM 2011 dialogs.

Continuing with our scenario of designing a dialog process to create a case record for the account entity, if you open the Specify Condition dialog and click the drop-down in the editor, you will see something like the following:

 

As you can see, the drop-down list has three sections. The first two – Primary Entity and Related Entities – work exactly the same for workflows and dialogs; the new stuff is in Local Values.

 Primary Entity refers to the entity the process is written for, in this case Account. If you select it, the next column lights up and allows you to select any of the fields from the account entity, which you can then perform conditional tests on.

 Related Entities refers to the entities that have a parental relationship to the primary entity of the process. So in this example, every record type that has a 1:N relationship to account is available; if you select one of these you can then perform conditional tests on any of the selected entity’s fields.

 Local Values presents several categories of items that can be used for conditional testing. These are listed briefly here and described in detail in the following table:

  •  Records created by the current process.
  • Process. Exposes the Execution Time, Activity Count, and Activity Count Including Process variables.
  • Dialog. Exposes variables defined for the dialog.
  • Responses. Exposes the response values provided by the user.

Queries. Exposes a special Records operator you can use to test how many records were returned by a Query CRM Data action.

As I mentioned, the most important new concepts for dialog processes are in the Local Values section, and they are important enough to deserve their very own table. In this table, I only include the items that are specially designed for use in dialog processes, and only appear when you specify conditions for dialog processes:
Local Values Item How it’s Used  Examples
Dialog  Variables are a new concept, available for storage of local values within a dialog process. If you’ve defined one and select Dialog, you can select it in the second column and test its value. Define a variable Rating to rate a lead record. Increment its value depending on a user’s responses in a dialog, using the Assign Value action. Perform conditional testing to qualify/disqualify the lead. 
Responses  These are the values provided by a user to a dialog prompt. If you select a response value, the fields available in the second column depend on the type of response selected.
  • Branch to specific pages based on a user’s response
  • Prompt user to “Create additional record?” and run dialog recursively if Yes
Queries Dialog processes have a Query CRM Data action you can use to build queries; lists of data returned by a query can be presented to a user in a prompt. If you select a query in the Local Values section, the second column exposes a special field, Records that you can use to test how many records the query returned. Define a query “Contacts for Account” to display all contacts for account, prompt user to select one as “Responsible Contact” for created case record. Use Records field to verify contacts exist for the account.

  • If exist, prompt user with query results, update case record with selected contact.
  • If not, skip prompt and update.

 

I know these concepts might not be crystal-clear at this point, but don’t worry: we will work through plenty of examples of how you can put them to work…starting in the next section, on the important topic of querying CRM data.

June 25, 2011 · Filed under CRM 2011, CRM 2011 Business Process Book, Workflow and Dialog Processes

Leave a Comment