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.

Fields Overview

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

Note:
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.

Field Types

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.

Note:
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.

Below you will find a table which gives a more detailed definition for each data type;

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;

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.