MB2-716 (Microsoft Dynamics 365 Customization and Configuration) – Dialogs

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at how to configure dialogs.

I hesitate to write this post! Why? …… it’s because Microsoft have recently announced that dialogs are to be deprecated. Meaning that they will “disappear” from Dynamics 365 at some point. Because of this I can’t recommend anyone starts using them. (You should probably look into task flows and business process flows instead.)

But this series of posts is all about helping people revised for the MB2-716 exam! Dialogs exist today and are included in the skills measurement statement. We could therefore still be questioned on them. And as a result I felt I should still include them in my revision guide. Below you can see the areas of the skills measured statement that mention 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.

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 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 used 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 attribute of the process session record when the process session is finished.

To view the process sessions for a dialog, yo navigate to settings and then the processes option. In here you can open the dialog and you’ll be able to use the “Process Sessions” option to review details of when the process was run.

Below you can see that I have opened one of my process sessions. I can see full details of what the process did, including an option to allow me to review any comments entered by the user. The process sessions would also be useful for fault finding, as you can see detail of all the steps in the dialog and if each one succeeded.

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.) Also notice, that like workflows custom actions can be created which can be called from dialogs.

You can insert a pages. 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’ve added 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 male contact I simply 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 smiple example.

Hopefully this post has given you a feel for what you might need to understand around dialogs for the Mb2-716 exam.

Please keep in mind …. Dialogs are due to be deprecated.

2 thoughts on “MB2-716 (Microsoft Dynamics 365 Customization and Configuration) – Dialogs

  1. Hello Neil, I am preparing for Mb2-716 . Should I skip “Dialogs” if its excluded from the exam since I have very little time to take the exam


    • Great question dialogs are deprecated. That just means they will go in a future version. Unfortunately deprecated features can still come up on the exam. Sorry but you probably need to know about them. And then never use them as deprecated. Joy!!


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s