I am creating a series of blog posts that collectively are designed to help anyone preparing for the Microsoft Dynamics 365 Customer Engagement Core exam. (aka MB-200) In this post I will look at concepts around fields.
You can see below that we have a section of the exam which covers managing entities and data. Within this section needing to know how to create and modify fields is referenced.
Each CDS entity is made up of multiple fields. Fields are sometimes described as attributes by developers, the two terms are pretty much interchangeable.
- Fields are used to store values of defined types. (For example a piece of text, a number or a date.)
- Sometimes fields of the same type can have different formats. (For example, a text field can be optionally formatted as an email address, URL, phone number etc.)
- Fields appear as controls on forms. (Such as a text box, date picker, radio buttons etc.)
- Fields can also be shown in user and system views and can be used as part of queries. (Advanced Finds.)
- For each field a “column” is created in its Common Data Service (CDS) entity.
- Fields can be “simple” or calculated.
- Fields can be created that contain rolled up values from related entities.
You Dynamics 365 instance can include system and custom entities. The system entities will already comprise of many out of the box fields but we can add more custom fields as required. Although it is always a good idea to check a suitable system field doesn’t already exist before creating a custom one.
When a custom entity is first created some fields will get created by default. You can see below that I have created a test entity and shown it in make.powerapps.com. Notice that I have one field called “neil_name”. The “name” field is a default primary field. By default this will be called name and will be a text field of 100 characters. It will also be a mandatory field. (Note: If required the field name, length and requirement level can be customized when the entity is created.)
My field is prefixed with “neil_”. This is because my publisher has a prefix defined as “neil_”. If you use the default publisher your field will be prefixed with “new_”. I will cover the concept of a publisher in greater depth when we revise solutions!
Swapping to the classic entity maintenance screens will show me that actually many more fields get created!
Including things like created on, created by, owner and many more. I doubt you will need to know exactly what these fields are but even so it is worth creating a custom entity and before adding your own custom fields have a look. Below you can see that I have done just that. With a “basic” user / team owned entity I have 19 fields before I start adding any custom ones.
Also notice that a field called “neil_testoffieldid” has been created and this has a type of primary key. This is the “id” or GUID field of this entity, all entities will have a GUID.
Note: A GUID (global unique identifier) is a term used by Microsoft for a number that its programming generates to create a unique identity for an attribute.
As mentioned that are essentially three types of fields, simple, calculated and rollup fields.
- Simple, these are “normal” fields that contain data not based on any formula. Examples include test, option sets, whole numbers etc.
- Calculated, contain calculations to derive their content. (Calculated form fields on the current or related parent entities.)
- Rollup, contain a aggerated value computer from the related records.
In this post my focus will be simple fields. I will cover calculated and rollup fields in more detail in later posts.
Each type of field will have a data type. You may need to know which data types can be applied to which field types. See table below;
Notice that some field types, such as lookup, can not be a calculated or rollup field.
|Field Type||Data Types|
|Simple||Single Line of Text
Multiselect option set
Floating Point Number
Multiple Lines of Text
Date and Time
|Calculated||Single Line of Text
Date and Time
Date and Time
Below you will find a table which gives a more detailed definition for each data type;
|Field data type||Description|
|Single Line of Text||Up to 4000 characters of text. You can set a maximum length less than 4000! This field has several format options that will change the presentation of the text. Including
|Multiple Lines of Text||Up to 1,048,576 characters of text. You can set a maximum length. When you add this field to the form you can specify the size of the field.
|Option Set||This field provides a set of options. Each option has a number value and label. When added to a form this field uses a select control and only one option can be selected. When displayed in Advanced Find, you can use a picklist control to select multiple options to include in your search criteria.
You may define a single global option set and configure multiple option set fields to use that single set of options.
|Multiselect option sets||Like option sets provides a set of options but allows the user to select more than one option.
Multiselect option sets can also make use of global option sets.
|Two Options||This field provides two options. Each option has a number value of 0 or 1 corresponding to a false or true value. Each option also has a label so that true or false values can be represented as “Yes” and “No”, “Hot” and “Cold”, “On” and “Off” or any pair of labels you want to display.
Two option fields don’t provide format options at the field level. But when you add one to the form you can choose to display them as radio buttons, a check box, or a select list.
|Status||A system field that has options that generally correspond to active and inactive status. Some system attributes have additional options, but all custom attributes have only Active and Inactive status options. You can also include custom state transitions to control which status options are available for certain entities.|
|Status Reason||A system field that has options that provide additional detail about the Status field. Each option is associated with one of the available Status options. You can add and edit the options.|
|Whole Number||Integers with a value between -2,147,483,648 and 2,147,483,647 can be in this field. You can restrict the maximum or minimum values in this range. This field has format options None, Duration, Time Zone, and Language that change depending on how the field is presented.
None – Simply displays a number.
Duration – Stores number of minutes in the database but can be displayed as x minutes, hours or days.
Time zone – Each time zone is stored as a number. (e.g. “(GMT-08:00) Pacific Time (US & Canada)”, TimeZoneCode is 4.)
Language – Each language provisioned is held as a four or five digit number.
|Floating Point Number||Up to 5 decimal points of precision can be used for values between -100,000,000,000 and -100,000,000,000 can be in this field. You can specify the level of precision and the maximum and minimum values.
|Decimal Number||Up to 10 decimal points of precision can be used for values between -100,000,000,000 and -100,000,000,000 can be in this field. You can specify the level of precision and the maximum and minimum values.
|Currency||Monetary values between -922,337,203,685,477 and 922,337,203,685,477 can be in this field. You can set a level of precision or choose to base the precision on a specific currency or a single standard precision used by the organization.
|Date and Time||This field has format options to display Date Only or Date and Time.
|Image||Each entity that supports images can have one image field. When an entity has an image field, it can be configured to display the image for the record in the application.|
|Lookup||A field that allows setting a reference to a single record of a specific type of entity. Some system lookup fields behave differently.
|Owner||A system lookup field that references the user or team that is assigned a user or team owned entity record.|
|Unique Identifier||A system field stores a globally unique identifier (GUID) value for each record. Also known as an ID field.|
|Customer||A lookup field that you can use to specify a customer, which can be an account or contact.
The customer field is document here.
So far the screen shots I’ve used have generally been from the classic interface for maintaining entities. You need to be aware that we currently have two approaches to maintaining entities. The classic (old) approach and make.powerapps.com the newer interface. The screen shot below shows that pretty much all the same types are available it is just that the screen layout is different. The exception to this rule is the autonumber option on text fields. As this is only accessible in the newer make.powerapps.com interface.
Creating / Maintaining Fields
When we create a field the screen looks like this (whilst using the classic approach to maintaining fields);
For completeness the equivalent screen from make.powerapps.com is shown below;
The table below covers the detail of each field, as always I strongly recommend you experiment with creating different types of fields;
|Field Requirement||Three options exist;
|Searchable||Yes/no field. Entering no here means the field will not show as a filter field in advanced find.
|Field Security||Fields that are available for field security will need to be enabled here. Not forgetting a Field Security profile will need to also be defined.|
|Auditing||Setting this field to enabled will enable auditing on this field. (Assuming auditing is also enabled for the organisation and entity.)
For the exam it is worth being aware that auditing needs to be enabled at an organization, entity and field level.
|Description||A multi-line description of the field. This information will show as a “tip” when you hover the mouse over the field name in a form.|
|Appears in global filter in interactive experience||This option only applies if the entity is enabled for use in the Interactive service hub(ISH). With the ISH you can filter dashboards globally by one field from an entity. For example, you might wish to be able to filter cases by the date they were created.|
|Sortable in interactive experience dashboard||This option only applies if the entity is enabled for use in the Interactive service hub(ISH). Like the global filter this defines how data will be sorted within the ISH. For example, cases may commonly be sorted by their modified on date.|
|Data Type||As already mentioned each field will have a data type. This can’t be changed once created. Data types include Single Line of Text, DateTime, OptionSet etc.|
|Field Type||Can be simple (the default) or calculated. If calculated, you will need to save the new field and then the criteria for calculation can be defined.
Note: I will cover calculated and rolled up fields in greater detail in a later post.
|Format||Some fields types can have different formats. For example, a date field can be displayed as date time or just date.
Regardless of the format the underlying data is always stored in a common format.
|Maximum length||Some fields, such as text boxes can have their length controlled.|
|IME Mode||IME mode is used to enable entry of complex characters and symbols, such as Japanese Kanji characters.
Options include Auto (the default), Inactive, Active and Disabled.
|Precision||For some numeric value types, include currency, float and decimal the precision can be defined.
Note: For currency the default precision is “Currency Prevision” meaning the system default would be used.
|Minimum and Maximum value||Some numeric values will have a max and min value. Currency fields, for example can theoretically have a range from -922,337,203,685,477.0000 to 922,337,203,685,477.0000. You may change this to limit the valid values.
For example, if you had a currency value to hold someone’s salary the min value might be 0. (People tend to not earn less than nothing!) and the max might be 1,000,000. (I don’t know many people that earn more than this, although I guess they exist!)
|OPTION SETS||If you select the field type as being an option set several additional “options” become available. Including giving the ability to select a global option set or define option values specific to this field. Plus, you can select a default value.
FYI : I will cover option sets in greater detail in a future post.
|TWO OPTIONS||Two options data types show fields to allow you to define the two possible options and the default. Initially the options will show as No and Yes. But could be changes to “Approved/Unapproved”, “True/False” or anything.
In background a two option field always has a numeric value to 0 or 1.
|Behaviour (Date and Time)||For date time files you can select a behaviour. Options include “Use Local”, “Date Only” and “Time-Zone Independent”.
When the behaviour of a field is “User Local,” field values are displayed in the user’s local time.
When the behaviour of a field is “Date Only,” field values are displayed with no time zone conversion. The date portion of the value is stored and retrieved as specified in the UI and SDK. The time portion of the value will always be 12:00 A.M. The behaviour of this field can’t be changed once it’s saved. (Tip:
When the behaviour of a field is “Time-Zone Independent,” field values are displayed with no time zone conversion. The date and time values are stored and retrieved as specified in the UI and SDK. The behaviour of this field can’t be changed once it’s saved.
|LOOKUP and Customer||If the data type is a lookup you can enter the target record type and relationship name.
The relationship name will be defaulted but you can change if required.
Customer works in a similar manner to lookup but two relationship names are given, one for account and one for contact.
When we create a lookup field a relationship between the current entity and the lookup entity is automatically created. Making the process of creating a relationship for a lookup really simple.
|AUTONUMBER FIELDS||If the type of a text field is set to autonumber some additional fields are present to control hot the autonumber will be generated. These include autonumber type, prefix, minimum number of digits and seed value.|
I have covered a lot of detail in these revision notes! Taking time to get some hands on experience of creating fields is really important. A great revision exercise might be to create a custom entity with one field of each type, you can then really appreciate the differences in all the varied types of fields.
Despite covering a lot of detail about field there is more to come! In future posts I will expand on the details here to cover calculated fields, rolled up field, global option sets etc etc.
I hope this post will have helped anyone preparing for the MB 200 certification.