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

I would also like to suggest some form of ability to use variables, etc with Business Process Flows and the ability to view selected values through something similar to the Process Session that is available in dialogs currently.

Level: Powered On

The ability to both Query data as Christopher Mahanes mentioned, and pass variables to other dialog or actions as James Stevens mentioned are Important. Some other features that don't work in BPF:

1.) The ability to write lengthy questions/instructions/suggestions in the Prompt/Response.

2.)  The ability to use dynamic values in the Prompt/Response

Level: Powered On

I think the mobile task flow is very limited and its only for mobile. And with the BPF, if you have to query entities, you will have to use javascript, it does not support CRM query we normally do from dialog. With BPF we cant have loads of pages and controls that are driven by values selected in the previous steps.  In my view, BPF and MTF are not be a complete replacement for Dialog. Please keep the dialog untill a full replacement is introduced or at least the BPF and MTF improved with all the missing features of dialog.


Level: Powered On

Dialogs are the best to run Business Processes, as you can place any field on them to collect user input not only ones that are on entities, where you can ask user 10 questions then only update 1 field on entity. You may have ability to run Business Process Flows in Dialogs instead of on top of the form.

Since you do not support Dialogs we started to use IBM Business Process Manager for simply collecting user input then updating CRM, this could have easily be done in Dialogs! They can even have Navigate To, Navigate From  events in plugins!