Say No to local Option sets (but pay attention in PowerApps)

The use of global option sets in Dynamics is normally considered a best practice, the obvious advantage is the ability to reuse the same list of options in multiple fields inside the same entity or a different one.
Dynamics still allows the creation of local option sets but from version v9 there is another difference between Local and Global option sets: the External Value property:

This property is available only on Global option sets, when you create a local option this new property is missing:

External Value is intended for Virtual Entities, I understand it's not an everyday situation to deal with it, but this gives you another reason to avoid local option sets.

Today we live in the world of CDS and PowerApps, but the choice between local and global option sets is also inside the Canvas mode. If before the creation of fields was handled generally by System Administrators (in what we call today model-driven apps), today a larger set of user can face this dilemma.
Microsoft published a detailed page regarding option sets inside PowerApps here:
Create an Option set
So make your users aware of the "Option sets" inside the navigation pane:
Although I agree with the warning written by Microsoft

"Local option sets can only be used by the entity and field they are created against, and cannot be reused on other entities. This approach is only recommended for advanced users that a specific need for a local option set."

teach your users that the options inside a global option set will be available in all the fields using that option set, so if you add or remove options this will affect also other fields created by different users based on the existing option set.

Don't use getSelectedOption().text

OptionSet is a particular field in Dynamics CRM, basically is a key-value pair array, where the key is an integer and the value is a string.
Xrm Object provides several methods to interact with an OptionSet field, including the infamous getSelectedOption. But why a developer should avoid a supported Xrm method? The reason is simple, it can easily lead to JavaScript errors, as the getSelectedOption().text case.

getSelectedOption returns the selected option as an object with this structure:

// CustomerTypeCode OptionSet - Account Entity
{"value": 8, "text": "Prospect"}

It's true that we can access the object properties in order to get the label using the syntax getSelectedOption().text (and getSelectedOption().value) but only if the OptionSet field is not empty. If there isn't a value selected, the getSelectedOption() will return null and not an object.

// this code generates an error if the field is empty
var customerType = Xrm.Page.getAttribute("customertypecode").getSelectedOption().text;

A workaround is to check if the object is not null:

var customerType = "";
var option = Xrm.Page.getAttribute("customertypecode").getSelectedOption();
if (option != null) {
    customerType = option.text;
}

But Xrm object provides a separate method to retrieve the text of a selected OptionSet, this method is getText, and more important when no option is selected, getText will return an empty string value.

Error-free code:

var customerType = Xrm.Page.getAttribute("customertypecode").getText();

In the same way the standard getValue() must be used instead of getSelectedOption().value, it returns the integer selected value or null if the field is empty:

var customerValue = Xrm.Page.getAttribute("customertypecode").getValue();
if (customerValue != null) {
    // ...
} else {
    // ...
}

Note that getSelectedOption() can be still used in some scenarios, for example when we manipulate the OptionSet using AddOption,RemoveOption or getOptions methods and we want to compare the selected option as object with other values, but never use it to just retrieve the selected OptionSet label.