Leon's CRM Musings: Using Dialogs for More Than Just the Call Centre

A lot of the marketing about Dynamics CRM 2011 dialogs describes them as being like a call script and, while they can be used for this, they are a lot more powerful than simply a way to guide users through a call.

In this example I’ll show how we can use dialogs for an internal process such as timesheet capture.

So What Are Dialogs?

Dialogs can be thought of as a new kind of workflow. In this case, there is scope for user input. Another difference is that, while workflows are generally triggered off an event in the system e.g. the creation of a record, dialogs can only be run ‘On Demand’ from a record. Similarly, while a dialog can spawn a child dialog or a workflow, a workflow cannot spawn a dialog.

Creation of a Timesheet Record

In this case I’ve made the record reasonably simple:

We have the obligatory Name field, compulsory for all entities, we have an owner, in this case the administration account creating the record, the Consultant who is doing the work, the customer (an account in the system), the consulting hours, travel time, a description field and a processed tickbox to show when a timesheet has been invoiced.

The Dialog

The dialog is going to spawn from the user’s record and it is available as a child process. Making it available as a child process means I can call it again to enter multiple timesheets at once. Everything else you see, I’ll explain below.

Querying My Customers

The first thing I do is query the database. This is a new feature of dialogs, sadly unavailable in workflows. In this case I’ve created a many to many relationship between users and accounts so I can track who a given user’s accounts are.

The query then retrieves these accounts so we can assign the timesheet to the right account.

Here the query looks for accounts where the many to many relationship is with the current user. My initial design was to query based on the user record the dialog was spawned from. However, while you can add dynamic parameters (slugs) via the ‘Define fetch XML query text’ tab, for user queries you need to feed it the user name and GUID. I can get the user name from the user record, but I could not find the GUID and therefore settled with the current user.

Displaying the Dialog Page

Now we have our query we can display the results and ask the questions we need to fill out a timesheet.

In the case of the customer selection, we add a prompt and response, referencing our query.

This will provide a list of accounts, associated to the user with a radio button selection next to them. It will then be up to the user to select the right company. Rather than account, this could easily be opportunities or a custom project entity. The difference is in the CRM Query used in the previous section.

The next two prompt and response boxes simply ask for user input, in this case totals for the consulting hours and travel time. Here is an example of the first one.

The data type field will only accept Text, Integer or Float. You cannot enter a date, for example. This is unfortunate and hopefully will be adjusted when the full version is released.

Finally, we have a question as to whether there is another timesheet to enter.

Creating the Timesheet

Once we glean all of this information from the user, we can create our timesheet entry under the user record. This works just like it did in version 4 workflows.

Respawning

Our final step is a conditional which looks at the value given for the ‘Another Timesheet?’ question. If the answer was ‘Yes’, the dialog is called again so a new timesheet can be entered. If the response was ‘No’, the dialog simply ends. One thing that tripped me up here is that the default is to compare against the response Value and not the response Label. Therefore you need to be careful you are comparing ‘Yes’ to ‘Yes’/’No’ and not to ‘1’/‘0’.