This post forms part of a series I’m creating aimed at helping people prepare for the MB2-712 certification. (Microsoft Dynamics CRM 2016 Customization and Configuration). In previous posts I have looked at workflows and Business Process Flows, this time I will build on the topic of processes by looking at Dialogs.
Dialogs are a process type that runs real-time delivering a wizard style interface to users.
Dialogs work on a principle of pages and prompts / responses. Each dialog is made up of a number of pages, each page contains a number of prompts. The responses from those prompts can be used in actions to create / update records etc.
The wizard styles interface fits very well with agent scripting in call centers. And because of this you will find “tips” that can be associated with each prompt. The tips give space for an agent script or notes to aid them when following the dialog.
As with most of these things, looking at a simple example might best explain the concepts of dialogs. Keep in mind that this is a simple example, you should play around with dialogs as they can be quite a powerful addition to CRM. (Although one I often find under used!)
Example of Running a Dialog
In my example I have created a dialog to act as a guided process for adding a new contact to an account. To be able to start the dialog I first load an account. Then select the “Start Dialog” option from the ribbon bar. (As shown below.)
After clicking “Start Dialog” the popup below is displayed. In this simple example I only have one dialog activated for the account entity but in a real world situation you could have many dialogs available to aid with the multitude of processes operators need to complete.
When the dialog runs users are presented with pages that look like the example below. When creating a contact, I have decided to prompt for name and date of birth first.
Notice the Tip column. In my example I have left this blank. The concept here is that instructions the operator might find useful could be displayed. Including maybe any specific information the user should mention to the customer. This is why dialogs are often used in contact center situations for agent scripting.
Having completed page one the user will click next, this will display page two. (Then 3, 4 and so on!) And of course we then have a previous button, providing a wizard style interface to allow us to navigate the prompt / response pages.
Eventually on the last page the operator will click “Finish” and the contact will be created against the account.
Most of the fields in my example have been simple text boxes. But you should be aware that date pickers and option sets are possible.
It is also possible to default fields or derive fields from others entered etc. I did say this is a simple example!
I showed Gender here for a reason! Firstly, as it illustrates an option set. But also because I needed to be creative on how gender was updated in my process. (More on that in a second!!)
Now you have looked at now a dialog is used, we should consider how to create these. So let’s look at that next.
You may have noticed the comments section of the dialog above. The comments section at the bottom of the page can be sued to take notes whilst the dialog run. This section is common for the entire session. The user can capture information such as feedback about the dialog or customer comment. The comments are stored in the description atttribute of the process session record when the process session is finished.
Creating a Dialog
Dialogs are created in the processes section of settings. Just like workflows and business process flows.
When processes are created, like other processes, they will need to be activated before becoming available to users. You can also not edit a process with deactivating it first.
Dialogs can be deleted but you will need to deactivate them first. As you cannot delete an active dialog.
When a dialog is created you will first set a number of properties. This screen operates in a very similar manner to workflows except there are fewer options with a dialog. Generally speaking we will simply give a dialog a name. There is however a “As a child process” option. You might want to experiment with this! As one dialog can be called from another one.
Next we will focus on the dialog process. Under the steps areas we actually have three parts to a dialog. Although simple ones may only contain steps, you should be aware of “Input Arguments” and “Variables”.
Input Arguments enable data to be passed between parent and child dialogs. The input arguments are defined in the child dialog and values passed from the parent. Child dialogs are added to a parent using a “Link Child Dialog” step. In this step you can map the responses from the parent to input arguments in the child. I did say you should experiment with child processes. This is why!
Variables allow storage of intermediate values such as concatenated strings or calculated data. As the pages progress the results from the “prompt and response” steps are automatically stored in step variables. Step variables might be used when you want to derive and store data based on the step variables.
Steps, Steps can be used to create records, update records, start child workflows etc. (In a very similar to you may be familiar with on “normal” workflows.)
Alternatively, you can insert a page. Each page then contains a number of prompt and response fields. Below you can see a page from my example dialog in which I prompt for first name, last name and data of birth.
Clicking “Set Properties” allows us to control how the prompt will operate. An example of my first name prompt is shown below. This is a very simple example but I hope you will start to understand that I can have different response types, such as option sets. I can also offer default values, that may be based on other fields on the entity etc. As part of your preparation you should experiment with some of these options to get a feel for the possibilities.
In my simple example I have several pages to capture the contact details. Then at the end of the process I have added some steps to create (and update) the contact record. As shown below.
The first step I have add created the contact, its properties are shown below. Notice that I can use the variables collected in the prompt and response steps to populate the contact information.
Great! But why have I got an update statement??? When I create the contact I default the gender to female. At the time of creation, I couldn’t set the gender as the format I used in the prompt and response did not match the data held on the contact entity. If the contact is a female, I don’t need to do anything. But when creating a man I simple update the contact and set the gender field accordingly.
This gender update demonstrates how you can use conditions and updates within a dialog. And I hope you can appreciate that dialogs could get quite a bit more complicated / powerful than my silly example. Enjoy.
Hopefully this post has given you a feel for the what you might need to understand around dialogs for the Mb2-712 exam. J