MB2-716 (Microsoft Dynamics 365 Customization and Configuration) – Option Sets

As I prepare for my MB2-716 exam I’m producing a series of blog posts that collectively should help others revising for the MB2-716 Certification. (Microsoft Dynamics 365 customization and Configuration.) This time I will look at Option Sets.

Option sets are simply pick lists. The value that is stored in the database is actually an integer but in the entity definition we relate each number to a text label. The text label shows as an option name on Dynamics 365 forms, views etc. As an example I have created an option set. I’ve added it to a custom entity I use to hold “policies”. My option set is called policy type and holds values like “Car”, “Home” etc.


Below you can see the field definition for this field from my policy entity.


  • Data Type, option set!
  • Use Existing Option Set, in this first example I have said no. This means the list of options is specific to this entity, this type of option set is known as a local option set. (I will describe how this option can make use of global option sets later in this post.)
  • Default Value, in my example I have set this to car, meaning new policies would default to being for car insurance. (You can leave this set to “Unassigned Value” if you don’t wish to define a default.)
  • Options, I created the list of options by pressing the green “+” button.
    • On the right had side I entered a label for each option.
    • The value field will default but you can change it if required.
    • For the default publisher all values will start at 100,000,000 but other publishers can default to different ranges. This helps to identify who added what options.
    • The description and color fields are optional.
    • Having added the options, I can use the arrows to manually change the sort order. Or the A-Z icons can be used to sort alphabetically.

Global Option Sets

If I expect to re-use an option set that it can be created as a global option set. This gives several advantages;

  • Re-using the options sets is more efficient as it saves the time of repeatedly entering lists.
  • If an option is added or changed, making the change once will affect all occurrences of that list in the system.
  • Reporting is consistent across the multiple entities the use the options.
  • Mapping of global option sets does not present any issues with data inconsistency. (See notes below on mappings!)

To create a global option set, I create it as before. But this time I answered “Yes” to the use existing option set question. If your option set already exists, you can simply pick it at this stage. But the first time you need it you’ll select the “New” option. You can then proceed to create the list.


Tip: Global options sets also appear in your solution under the heading of option sets. You can also create them from there if required.


After creating a global option set you can use the edit button to add new options or change existing ones. These changes would apply to all the occurrences of the global option set.

You do need to be mindful of deletions! (On local and global option sets.) If the option is currently being used the existing records will not actually be changed. But when you view them they are going to show as blank as the option no longer exists. And you won’t be able to use Advanced Find to locate them as once deleted you wouldn’t be able to select the old option in your search criteria. Therefore if you do need to delete an option set item it is good practice to update the existing data prior to removal of the option.

Mapping Option Sets

I haven’t covered relationships and mappings yet. So at this point don’t worry about how to create mappings. It is enough to just know that mappings are used to default fields on child entities when created from a parent. You often see this happen in Dynamics 365! For example, when you create a case from an account form the account name is populated onto the case using mappings. Some mappings are part of the system and can’t be changed but often developers will create custom mappings.

I mention this here as there is a specific concern with option sets. Something you will need to be aware of!

What is “special” about option sets is you need to keep in mind that the option set value is mapped not the text. Imagine you map an option set on one entity to another option set. What will happen if the combinations of text and value do not match. To illustrate this, I have shown two option sets below. One as it might appear on my parent entity and one on a child.

Parent Entity Child Entity
Text Value Text Value
Car Insurance 100,000,000 Car Insurance 100,000,000
Home Insurance 100,000,001 Pension Fund 100,000,001
Life Insurance 100,000,002 Life Insurance 100,000,002
Savings Policy 100,000,003 <<Blank>>
Pension Fund 100,000,004 <<Blank>>

If Car Insurance or Life Insurance is selected on the parent, a new child entity would show the same result. As their values match on the parent and child.

But selecting Home Insurance on the parent would show Pension fund on the child! As both have a value 100,000,001 but they have different text values.

Selecting Savings Policy or Pension Fund on the parent would result in nothing being shown on the child. As it is not aware of those options.

Hopefully I have covered most of the key points you need to understand connected with Option Sets for the MB2-716 exam.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s