Skip to content

Instantly share code, notes, and snippets.

@gotdibbs
Last active February 10, 2017 16:16
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gotdibbs/4679f0afecfef8ef46fb81c27f7e74b9 to your computer and use it in GitHub Desktop.
Save gotdibbs/4679f0afecfef8ef46fb81c27f7e74b9 to your computer and use it in GitHub Desktop.
Multi-select Blogpost

Today's blog post was written by William Dibbern, Principal Developer at Sonoma Partners.

Introducing Multi-select for Dynamics 365 for Sales

One request that we receive a lot is to allow users the ability to select multiple values from a pre-defined list. Say your organization tracks contacts and you would like to keep track of the interests of those contacts.

Natively, one way to accomplish this in Dynamics 365 for Sales, without custom code, is to create an many-to-many relationship with a custom "Interests" entity. This is all fine until you ask a user to enter this data in repeatedly, quickly and there the user experience falls apart. A user must remember what all the predefined interests are in order to use the autocomplete functionality, or must interact with a lookup dialog in order to search through the available options. This either means your user is enduring a heavy cognitive load or a bunch of clicks. Not as good of an experience as it could be.

To solve for this gap, we crafted a managed solution that recreates the most common user experiences for multi-select controls from across the web, with the goal of making the user experience a little bit easier.

Let's take a walk through some of the pre-built custom user interface options we have inside this new solution.

Checklist

Using the Checklist control, users can select the records they desire simply by clicking on a checkbox. No typing, only one click needed. If desired however, users are also able to search through options using the provided search box, and filter down to see only what has been selected using the All and Selected view toggles.

Checklist Control Example

Use this control when: when saving space on a form is key, when you have a smaller data set, users enter and edit data more often than they are referencing it.

Listbox

Using the Listbox control, users can click Edit which will bring up a dialog that presents them with all of the available options. Within this dialog, the user can select multiple options by holding the [shift] key, or by searching for a specific value. Once an option or multiple options are chosen, they can be moved to the Selected column by pressing the >> button.

Listbox Control Example

Use this control when: when saving space on a form is key, when you have a larger data set, users reference the data in question more often then they enter or modify it.

List View

This control is very similar to the Checklist control, but the formatting provides for a lot more information about each option to be displayed to the user. Using the List View control, users can select the options they desire by clicking on the checkbox next to the description and are able to search for specific items. No dialog to get in the way so we keep the click count low. Users are also able to click on Selected to view only the selected items.

List View Control Example

Use this control when: space savings aren't necessary, you'd like to use a custom item template to display more information about an option, when you have a smaller data set, when users are entering or modifying data more than they are referencing it.

Selectize

This version of the multi-select is based on a popular library called Selectize, thus the super clever name. Using the Selectize control, users can click into the field and select the records they desire by clicking on the option's description or by using the arrows and [enter] keys. Once items have been selected, they can view them within the field and remove them by clicking the small x or deleting them with their keyboard.

Selectize Control Example

Use this control when: when saving space on a form is key, when you have a smaller data set, when users already know the data set they're selecting from.

Installation and Configuration

The multi-select solution is available as a Dynamics CRM 2015 managed solution which you can readily download from our website here. This same solution will work in Dynamics CRM 2016 and Dynamics 365 for Sales. Once downloaded and imported into your environment, you'll have some configuration to do depending on how your data is set up. We would recommend that you have prior knowledge of Dynamics 365 for Sales customizations before diving right in, as there is some limited technical knowledge required to configure this solution.

The mulit-select solution supports custom item templates (HTML) and many other options, but for the basics, you'll need to at least pick a method by which data is read from and stored in Dynamics 365 for Sales. The multi-select solution supports the following common backing data structures, noting there are pros and cons to each which must be evaluated on a case by case basis:

  1. Display data from a global option set and store selected values in text fields. Using this method, the options come from the global option set, and one or (optionally) two text fields are used to store the selected values.

Pros: storing data this way makes it a bit easier to search through when working with quick find views or advanced find.

Cons: if you tell any database guru you're storing a list of values in a single column, they'll probably freak, and they wouldn't be entirely off-base to do so. Storing data this way can make things harder down the road like reporting, migrations, etc.

  1. Display and store data from a custom N:N relationship. Using this method, a custom intersect entity is created between two entities (three total entities involved) and these custom intersect records are created when options are selected.

Pros: your resident database guru won't argue as much with you on this route, you have the option to store more data on the intersect record if desired, you can control the state of your intersect records and capture who created/modified them and when.

Cons: searching through your data using advanced find and quick views becomes more difficult.

  1. Display and store data from a native N:N relationship. Using this method, records are associated and disassociated according to what is selected.

Pros: again your resident database guru won't argue with you as much, and you get to skip creating a custom intersect entity.

Cons: similar to the second option, searching through your data using advanced find and quick views becomes more difficult.

Once you've determined how your data is to be read and stored, you're ready to get things configured. If you're ready to proceed, head on over to our documentation for more detailed instructions on how to configure the solution appropriately, and of course feel free to drop us a line if you have any questions or encounter any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment