Backgrounder
In Dynamics CRM 2011,
workflows work much the same as they did in the 4.0 version. But now, in addition to workflows, an important new kind of business process has been added:
Dialogs can do many of the same things as workflows, but they are different in several important ways. The following table contrasts these two different kinds of processes (which incidentally, are each considered a specific kind of
Processand exposed that way in the UI):
| Workflows | Dialogs |
| Asynchronous | Synchronous |
| Can be triggered by events or run on-demand | Cannot be triggered by events; always run on-demand |
| Never require user interaction to complete | Always require user interaction to complete |
| Can be run on multiple records | Can only be run on one record at a time |
| Cannot build interactive queries of CRM data | CAN build interactive queries of CRM data |
The most fundamental way dialogs differ from workflows is in their support for a user interface; in the design environment it’s the
Page that provides the basic container for the UI. In fact, you cannot save a dialog process without at least one page.
In turn, the page is a container for one or more
Prompt and Response pairs. Together, pages and prompt/response pairs provide the UI and allow you to create a wizard-style experience for your users. For example, Figure 1 displays, in the design environment, a very basic dialog process.
Figure 1: An Interactive Dialog Process in the Design Environment
Figure 2 shows what that will look like this to a user running the dialog process:
Figure 2: The User Experience for a Basic Dialog
Although this dialog process will run, it doesn’t do much other than illustrate the basic Page and Prompt and Response components. But even in the most basic dialog process you can tell there are some significant differences between dialogs and workflows. For example, here’s a side-by-side comparison of the options available from the Add Step menus in, respectively, the
workflow design environment and the
dialogdesigner:
Figure 3: Add Step Drop-Down Menu for Workflows | Figure 4: Add Step Drop-Down Menu for Dialogs |
You can develop some intuition on the differences between workflows and dialogs from this comparison: for example, notice that dialogs don’t have the Wait Condition and Parallel Wait Branch conditional constructs that workflows do. This ties back to the fact that dialogs always run synchronously and always require a user to interact with them through to completion. You couldn’t very well add a six-month wait condition in a dialog and expect a user to sit around and wait for it!
Querying CRM Data in a Dialog Process
But the topic of this article is what you can do in dialogs that you
cannot in workflows. We already reviewed the Page and Prompt and Response constructs for the UI, but what I want to focus on here is the
Query CRM Data action. You can use this to allow users to select, in one of the Prompt/Response pairs, from a list built from a query. For example, you might create a dialog process as a substitute for the standard form experience in creating a case record. Instead of filling in a form, you walk a customer through a series of prompts, record the responses, and after the dialog finishes, the rest of the process creates the appropriate records. One of the prompts might be “What’s the name of your company?”, for which you can use
Query CRM Data to build a query of accounts, allow the user to select from a list of accounts eligible to open a case, and then create a case record attached to the selected account.
I’ll illustrate this with an example. Suppose cases are opened for accounts, and for accounts with “Preferred Customer” in the category field, cases get routed to a special queue. Here’s an Advanced Find view that will return all Preferred Customer accounts:
Now we’ll see how to build a dialog that presents the user with a list of accounts based on that query, allows the selection of an account, and creates an appropriate case record for the selected account. In this example, we’ll assume that a phone call kicks off the case intake process, and base the dialog on the phone call entity. Follow these steps to …
- Create a new process (click Settings, then click Processes, and then clickNew)
- Give it a name, select Case in the Entity drop-down, select Dialog in theCategory drop-down, select New Blank Process in the Type section, and then click OK.
- When the process design window opens, click where it says Select this row and click Add Step, click the Add Step drop-down list, and select Query CRM Data.
- Then click the set Properties button and you’ll see the Define Query dialog
- You can see that this is just a specialized version of Advanced Find, so selectAccount in the Look for drop-down.
Next you can take a couple of different approaches. If you don’t mind building your query on the fly, you can simply build it here; on the other hand, if you’ve saved it as a view, you can select it in the Use Saved View list. In the end, it amounts to the same thing, as you can see in the following figure:
- Click Find to verify the query works as expected, and then click Back to Query when you’re satisfied.
As you will see shortly, the Statement Label is important, so I’ll be careful and give mine a good name, say, “Preferred Accounts”, then click Save and Close.
Now it’s time to build the UI for the dialog process, starting first by adding a Page, which will be the container for the Prompt and Response pairs:
- Click Add Step and select Page from the list.
- Provide a name for the page, and then click the line below it. Now click Add Stepagain and this time select Prompt and Response.
Click Set Properties and you’ll see the Prompt and Response dialog. Following this example, set the following properties:
- Statement Label: “Selected Account”
- Prompt Text: “Which Account are you with?”
- Response Type: Option Set
- Data Type: Text
- Provide Values: Query CRM Data
After selecting that, you’ll see that Query Variables lights up, and you can select the Query built previously (hence the importance of good naming!). Select at least one field to return by checking in one of the columns, and when finished you should see something like this:
- Click Save and Close.
- Now the query’s built, and the dialog can do something with the value contained in Selected Account, which functions like a variable.
Since this article is about using queries in dialog processes, I’ll take a shortcut and build out the rest of the simple version of our case creation dialog. The simple version will ask another question, and then use the information gathered to create a case record, with the Selected Account entered in the Customer field. Here’s what the rest of the dialog looks like:
Figure 5: Dialog to Create Case Record
If you click the
Set Properties button I highlighted in the figure, you’ll see the
Create Case dialog. Use Dynamic Values to create a subject/topic, fill in the Customer field with the Selected Account (from the dialog), and fill in the Description field:
Figure 6: Create Case Record with Dynamic Values
Finally, refer back to Figure 5 and notice that records are routed to queues differently in CRM 2011 than they were in CRM 4.0, using the
Create action to create a new
Queue Item record.
Building Dynamic Queries
OK, that’s all well and good, but how do
dynamic queries work? To continue the case-creation scenario, consider the following requirements:
- Case records created using this process will be associated with the selected account entered in the Customer field. You saw this in the previous section.
- The case form will be customized to add a lookup field to the Contactrecord type. The dialog process will construct a query to allow the selection of contacts associated with the selected account record. This is thedynamic query, so-called because it will be constructed dynamically within the dialog process, using the value selected for account (in the first query) as a parameter for the dynamic (second) query.
Because the second (dynamic) query depends on the account selected from the first query, dialogs like this one always have a characteristic structure:
The Gather Information stage will be structured like this:
- Construct the first query with Query CRM Data
Insert a Page.
- The Page contains at least one Prompt and Response, and the label of the Prompt and Response will be used later in the dynamic query,
- Immediately after the Page created in step 2, insert another Query CRM Data. This will be the dynamic query. In the current example, it will have a name such as “Contacts for Selected Account”.
After the dynamic query, insert another Page.
- This page will contain (at least) one more Prompt and Response, which will allow the user to select one of the contacts associated with the previously selected account.
The Post-Dialog Processing stage will use the information gathered to do whatever the process is supposed to do.
The following figure illustrates this structure for the current example:
The first query is the same as the one in the previous example. The first Prompt and Response allows the user to select an account, and stores the selection in the
Selected Account variable. The second query is the dynamic one, and constructing it is the tricky part. Assume for now that all you have is the first part: the query for preferred customers and the prompt and response allowing a user to select one:
Follow these steps to create the dynamic query (
Contacts for Selected Account in the example):
- Click Add Step, and select Query CRM Data.
- Click Set Properties and select Contacts in the Look for drop down.
- Select Parent Customer from the list of fields, and then in the second column, select Begins With.
In the third column, enter a placeholder value – anything you want, since you’ll delete it in a minute. For example:
Now, click the Modify Query Variables tab. Until I learned this trick I always wondered what that tab was for! You’ll see something like this, which is the FetchXML you may have been hearing about lately:
Finally, delete the placeholder text, and select Selected Account in the Local Values section of the Look for drop-down, and then be sure to select Account Name, click the Add button, and then OK. After jumping through those hoops, hopefully it should look like this:
Finally (this time I really mean it!), provide a good name for the Statement Label, like this:
It takes a few steps to get it done, but at this point you can see that Variable1 is a parameter in the FetchXML, and that the value of the Account Name gets substituted into it at runtime, filtering the list of contacts appropriately.
I recorded a video that demonstrates how to make dynamic queries in CRM 2011 dialog processes. It’s in the customization section on the
Trick Bag Video page.
Summing Up
Seeing as how you got this far, the least I can do is summarize the most important points:
- This is a general technique, and can be used any time a value selected from one query can be used to filter another.
- The FetchXML used here is the same as that used in custom SSRS reports for Dynamics CRM Online, so skills developed in one application will pay off in the other.
- If you liked this, you’ll love the updated edition of my workflows book, coming soon with comprehensive coverage of workflow and dialog processes in Dynamics CRM 2011!
