Suggest a new Idea

    • 122

      Don't kill dialogs until these gaps are filled

      Suggested by Joel LindstromNew 10
      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.

    • 87

      Allow Business Rules to set visibility of a section or tab

      Suggested by Steven FayersNew 10
      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.

    • 34

      Business Rules should support form notifications

      Suggested by PETER ZIMMERMANNPlanned 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.

    • 26

      Ability to Dock "Tabs" on top of Unified Client Interface Tabs

      Suggested by Mohamed MostafaNew 5
      Category: Business Process

      Currently in the Unified Client Interface (UCI) Forms, we have Tabs on top of every form which is a great feature. Lots of our customers are very happy to see these tabs back at top of their forms.

      However, these tabs are not always visible and they disappear if you scroll down the form. Many of our customers are asking for the ability to "Dock" all UCI form Tabs even as an optional feature.

      Could you please add this feature to Dock UCI Form Tabs at the top of the Form so that they do not scroll down with the rest of the form?
    • 26

      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.

    • 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.

    • 23

      Business Rule Condition needs ability to test for the current user

      Suggested by VILLE VAINIKAINENPlanned 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.

    • 23

      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.