Showing results for 
Search instead for 
Did you mean: 

Don't kill dialogs until these gaps are filled

Author Name: Joel Lindstrom

It was recently announced that dialogs are deprecated in the next release. But what is the replacement for dialogs? The article suggests task flows and process flows, and while these are options for replacement of many types of dialogs, in their current form, they are not adequate replacements for all dialog scenarios. Let's consider several common dialog scenarios and how a task or process flow might replace them:

  1. Defined user actions on single records (think imitating or replacing system "close x" dialogs😞 adding fields to a process flow to collect data for things like qualifying a lead, closing and opportunity, or resolving a case can be a viable option, as long as this action is only done one time per record. As the final step to a process that closes out the record, process flow is a pretty elegant user interface. However, what if that action is performed multiple times per record? Unlike a dialog, users are not going to launch multiple instances of a BPF against the same record. If my dialog is used to initiate a user requested action multiple times against a record, business process flows are not a good fit in their current form, unless I concoct some method to clear out the fields used to initiate the action on the BPF.
  2. Multi-record update wizards: One of the more popular uses of dialogs is presenting a user with a form that consolidates multiple records into a single dialog, making it easy for a user to simultaneously update multiple records in a single step. For multiple clients, I have configured a "meeting close" dialog that simultaneously updates the related regarding account and contacts, adds a note, creates one or more opportunity, and closes the appointment. While task flows come close to this, their bound controls mean that you can only have fields from a single record per page of the task flow, they lack the ability to intelligently run in context of the record you are on, and they don't support looping child processes, so if I want to give the user the ability to create 1-N opportunities, I have to hard code the number in the task flows, and they only work on mobile, so I cannot make a wizard-based process that works for all users in all UI contexts.

So before "pulling the plug" on dialogs for good, the following are our suggestions on what should change to make task flows and process flows a more viable replacement for dialogs:

  • Free task flows to work with all user interfaces, not just mobile. Users want a consistent experience between mobile and web, and web users need wizard-based processes to make their lives easier too. I like your easy button, put it in the web too.
  • Give the option to have a task flow run in context of a record. Don't take away the ability to have it run from outside of a record--that is actually a good thing in some contexts. But give us the ability to have a task flow launch in context of a record when that makes sense, and make it as easy to call from a form script or command bar button as a dialog is.
  • Make it intuitive to update OR create records from a task/process flow. As Donna Edwards mentions in this great post, it is possible to create records from a task flow, however, you can't dictate whether a user is creating or updating a record when you design the task flow, and since the user must select the record to be updated from a lookup field, the process is not intuitive, especially if there are multiple related records without distinct record names.
  • Allow for child flows or looping processes: Consider the scenario where you are presenting the user with a wizard that can be used to quickly create multiple child records. That's easy with dialogs. My suggestion is to add the ability to call child process or task flows and pass variables to them contextually. This would close the gap of not being able to have users execute a sub-process an infinite amount of times, and would allow process and task flow designers the ability to reuse subprocesses like we currently do with dialogs and workflows.
Status: New
Level: Powered On
Status changed to: New
Level: Powered On

Dialogs also have the ability to query information and present that dataset back a user. 

For example, let's say i have a flow to send information for contacts. Marketing team have a entity called "New Sales Material" and I have a dialog that can query that table to only show "Current Sales Material".

A dialog can easily achieve this by having a query step that we can specify to show active Sales Material. I can even modify the variables in the query to show the user Active Sales Material based on the contact's account territory. Once I have the data set I can present this content in either a pick list or option set. Once the user selects which Sales Material they want i can generate an email with that detail send it to the contact.

I can go a step further with that response and pass it as variable into either a Workflow, Dialog or action.

In some aspects i feel dialogs are one of the most powerful process in Dynamics 365 and feel like if they are to be deprecated Task Flows need to have this capability.

Level: Power Up

Yes, exactely what we Need

Level: Powered On

The limitation in nb of BPF per entity and nb of steps is also a huge limitation. If we are to use them as a replacement to dialogs we need to create as much branches and BP as we want.

Level: Powered On

Task flows really have a lot of room to improve.