Suggest a new Idea

  • 97

    Don't kill dialogs until these gaps are filled

    Suggested by Joel LindstromNew 9
    Category: Business Process

    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.

  • 56

    Allow Business Rules to set visibility of a section or tab

    Suggested by Steven FayersNew 6
    Category: Business Process

    Currently the Business Rules allow setting the visibility of individual fields. It would be great to have it also available for sections and tabs.

  • 37

    OR Condition in Business Rules

    Suggested by ANDRE MARGONOCompleted 2
    Category: Business Process

    As Workflow condition recently got the OR operation, I think it is beneficial for Business Rules to get the same treatment. This will give more advanced functionality for customization.

  • 29

    Business Rules should support form notifications

    Suggested by PETER ZIMMERMANNPlanned - Short-Term 1
    Category: Business Process

    Business Rules currently support displaying an error message on field level, similar to the JS-Function setNotification().
    It would be great to have the choice to either display the message on field level and form level (like the JS-Function setFormNotification())

  • 28

    Payment specification on vendor bank account

    Suggested by Mihaela UrsuNew 1
    Category: Business Process

    User should be able to setup a default method of payment with corresponding payment specification on the vendor bank account used for the payment. One vendor may have multiple bank accounts and so setting payment specification behind each bank account for Switzerland is necessary.

  • 24

    Translation for [Business Process Flow] name

    Suggested by Takao MizushimaNew 0
    Category: Business Process

    [Business Process] name on [Cases] entity is displayed in the base language by default.


    For instance, base language is English and install Chinese langugage pack.
    Change the language from English to Chinese, and open a record on [Cases] entity.
    [Business Process] name is displayed in English.


    The issue isn't improved even though editing it after performing [Export Translations].
    This part of translation is missing.
    It would be much better if [Business Process] names are translated as expected.

  • 24

    Automate 'Business Process Flow' 'Stages'

    Suggested by Joe WolteringUnder Review 4
    Category: Business Process

    There should be the ability to move the stages of a business process flow automatically based on entering of data in required fields.

    e.g. I want to move the flow from Stage 1 to Stage 2 when fieldA is populated with value of X

    Expecting users to manually advance stages is dumb and counter-intuitive to what CRM is all about.

  • 22

    Business Rule Condition needs ability to test for the current user

    Suggested by VILLE VAINIKAINENPlanned - Short-Term 1
    Category: Business Process

    It would be a nice improvement to CRM 2013 business rule functionality to have more options for building conditions. In many cases it would be very helpful to check if an entity field equals (or not) the current user.

  • 22

    CRM 2011 Dialogs use Global Picklists for Prompt and Response Picklists

    Suggested by Jason CosmanUnder Review 4
    Category: Business Process

    Currently using Microsoft Dynamics CRM 2011 the Dialog Process allows for Prompt and Response pick lists. This functionality is great but there are limitations to it. It needs the ability to reference Global Picklists allowing the Global Picklists to become truly global throughout the system.

    A great example of this would be having a Picklist on the Case entity where a Dialogs main job was to allow the customer to select the Picklist value then automatically create the case passing through the Global Picklist value.

  • 21

    Arbitrary stage jumping on BPF

    Suggested by John GraceNew 1
    Category: Business Process

    The capability to have multiple BPFs on a single record in 8.2+ is a great feature. But from a server-side programming view-point you cannot arbitrarily jump stages. 


    We need to step-by-step, navigate the process programmatically and update the active stage one at a time on the generated BPF-entity. This is so the TP (traverse path) calculation gets triggered and to support the rendering of the process control on the web\mobile client.


    Ideally if we could just perform an update on the generated BPF-entity to arbitrarily jump stage & set the traversepath field in the same update command that would save developers a significant amount of time going forward but also reduce the time to upgrade server-side code from pre-8.2 versions as updating the processid & stageid fields is not supported going forward on the primary entity.