Building Business Processes in Dynamics CRM 2011: Installment 10

Custom Dialog Process to Resolve Cases

Previously, I characterized three broad scenarios for which dialog processes can be particularly useful:

• Creating records
• Converting records
• Closing records

Earlier we saw an example of using a dialog process to substitute for the standard lead conversion process. In this example and the next one we will examine using dialogs to replace the standard Case Resolution and Opportunity Close processes.

Once again, why do we need dialog processes for these scenarios? Why not workflows? Because case resolutions and opportunity closes often require additional information from the user, and since workflows don’t support this, dialogs are the way to go.

Here is the standard Resolve Case dialog box:

This form cannot be customized. For example, the Resolution text field is required and cannot be “un-required”. The ability to introduce a difference between Total Time (the sum of the duration fields on all closed activities for the case) and Billable Time is another aspect of the standard case resolution process that cannot be customized on this form.

In Dynamics CRM 4.0 we were pretty much stuck with this, apart from implementing custom close processes with plug-ins. But in Dynamics CRM 2011 we have dialog processes we can use for jobs like this.

For the example I show here, I’ve created a simple dialog process to close cases. It’s written for the Case entity, and only exposed as an on-demand process. Since by now the Properties section should be pretty familiar, I’ll skip that and go straight to the logic in the dialog designer.

As usual, I’ve divided this process into stages. Stage 1 consists of a single page with a single Prompt and Response, which gathers information from users on what they want to do with the case:

Stage 2 consists of a conditional block with clauses to deal with both the Canceled and Resolved options a user might supply in stage 1. The next two figures show the entire Stage 2 so you can see everything at a glance, but only highlight one clause at a time. First, if a user selects the Cancel option, two things happen:

1. The Update action updates the case record, with an informal time-stamp on the Description field.
2. The Change record status to action specifies the Canceled Status Reason, which forces the Status value to Canceled.

Here’s what it looks like:

Second, suppose a user wants to resolve a case. That’s handled in the Otherwise clause, which does three things:

1. Presents a page, this time with two Prompt and Response pairs.

   1. The first one presents an option set with five options for satisfaction level; these all correspond to the standard option set on the case form. (Remember to give this a data type of Integer!).
   2. The second one is a multi-line text field, allowing free-form notes to be entered about the case resolution.
2. After gathering that information, the Update action takes the response for Satisfaction Level and updates the corresponding field on the case form. And it takes the text entered into Case Resolution Notes and does a fakey time-stamp on the Description field.
3. And as always in these kinds of things, the Status Reason is changed to change the Status, and that has to happen last.

You can see those three steps in the following figure:

I mentioned the fakey time-stamp. This is a good trick and one I use a lot. There are of course lots of different ways of doing it; the following figure shows the approach I used here, combining static and dynamic values on the Update Case Set Properties step:

Also, notice that the Satisfaction field can be set directly to the Response Option Set Value. This is because the data type is Integer. (Forgetting to set it to Integer, and having to delete the step and re-do it, is probably the single most frequent mistake I make in designing dialogs!)

Here’s what this dialog looks like when it’s run; this figure shows the page from stage 2, with prompts being responded to:

Here’s what the resolved case looks like after completing the process:

Finally, here are a few summary points you’ll want to keep in mind for dialog processes like this one:

• If you examine a case record resolved in this way, you will notice it does have a Case Resolution activity created for it. However, unlike in the standard case resolution process, the case resolution activity record created when a custom dialog closes a case will not have anything in the Resolution field, and it will not total up the duration of closed activities for the case. If you want those values filled in, stick with the standard process.
• As far as I know, you cannot (easily) build a query to present the user with a dynamic list of status reason values. So if you add your own custom status reasons for the Resolved or Canceled statuses, you will need to manually update any option sets within the dialog that let users select them.
• The example I showed here was deliberately basic, since I mainly wanted to illustrate the mechanics. The next example – closing an opportunity with a dialog process – is a little more complex, but has some nice functionality to compensate.