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 CDS entities.

You can see below that we have a section of the exam which covers managing entities and data. Therefore you can expect quite a bit of revision to be required as this section can be up to 20% of the exam.

Entities are at the centre of anything and everything we do concerned with customising Dynamics 365, obviously it ships with many out of the box entities such as contact, case and phone call. Beyond this you can create your own custom entities to extend the capabilities of the base product. One important concern here is knowing when to use an existing system entity and when to create your own from scratch. You will hear the term common data service or CDS, as this is the location all of our Dynamics 365 entities reside. I will therefore begin by giving an overview of CDS.

Dynamics 365 is created using the Power Platform. The Power Platform includes PowerApps, Flow and Power BI. We have two types of PowerApps canvas apps and model driven apps. I won’t explain the differences between app types here! But for this purpose it is worth understanding that Dynamics 365 is effectively “just” a model driven app sitting within the Power Platform. Model driven apps locate their data in the common data service (or CDS for short). Data within CDS is stored within a set of entities. An entity is a set of records used to store data, similar to how a table stores data within a database. CDS includes a base set of standard entities that cover typical scenarios, but you can also create custom entities specific to your organisation

Entity Types

There are three types of entities in CDS, system entities, custom entities and activities.

• System Entities
  • Built-in entities which are created when a new organization is created. (Such as Account, Contact, Case etc.)
  • Most can be modified, such as account, contact etc.
  • Some system entities can’t be customized or have certain elements restricted.
  • Can never be deleted.
  • When considering solutions, cannot be locked down by a solution. (They will always be customizable!)
• Custom Entities
  • Can be created by system customizers to address specific needs.
  • Can also be created when importing managed or unmanaged solutions.
  • Can be fully customized. (Unless locked down with managed properties.)
  • Can be deleted. (Generally!)
• Activities
  • Used to log interactions with other entities, such as a phone call to a contact or an email to an account.
  • Some properties are predefined and can’t be changed.
  • All activity entities share some common fields within the activity pointer entity.
  • Share a common set of security role privileges, your access rights to emails, phone calls and tasks will always be the same!
  • Out of the box examples of activity include appointment, email, phone call and task.
  • You can create custom entities of type activity.
  • When required activities can be hidden from the activity menu.

Note:
I will cover the activity pointer entity in more detail in a later post. It is essentially a “special” join between the primary entity and the activity. Consider, for example, the “To” field on an email. The email can be sent “To” multiple recipients, plus some maybe contacts whilst others might be accounts, leads or even details from custom entities. Meaning the activity point allows us to join multiple records of multiple types to the activity.

Entity Assets

Each entity is made up of multiple assets. Later we will see that within a solution we can opt to include some or all of the entities assets. Assets are essentially the building blocks which make up the structure of the entity.

Note:
The screen shot above is from the classic method for amending entities. In this post I will attempt to use the newer style screens as much as possible! You can now access the maintenance of entities from make.powerapps.com, the screen shot below shows the more modern maintenance of entities. Generally speaking the features available in the classic interface and make.powerapps.com are identical. However you will find some minor differences. When I took the MB 200 exam I don’t recall any questions that were specific to one interface or the other. But regardless I still encourage you to become as familiar as possible with the newer interface. Unfortunately you may find the existence of two methods for maintaining entities confusing, we live in changing times and whilst the migration from old to new is completed some complexity may exist.

Assets include forms, views, charts, fields, keys, relationships, messages, business rules, hierarchy settings and dashboards.

One fundamental asset is fields, as they make up the heart of the entity. There are many different types of fields, including text boxes, date pickers, option sets etc. I will cover fields in detail in a later post.

We can also define form layouts, charts and views. And we can define how the entity relates to other entities. Plus, define business rules which contain logical rules that define how fields on the entity should behave, for example hiding and showing them as required.

Entity Ownership

There are two types of ownership for entities in Dynamics 365. User / Team ownership or organization ownership. Once the type has been set on an entity it cannot be changed.

Below you can see that I have started to create a new entity. Notice that the ownership field has two possible options.

Tip:
To be able to see the ownership field and many other parameters regarding your entity you may need to click the “More settings” option!

Note:
system activity entities or custom activities are always user or team owned. With those the ownership field cannot be amended.

Organization owned entities are available to the whole or organization (or not) dependent on security roles settings. Only the none and organization options are available in security roles for organization owned entities. Organization owned entities are useful for reference data that will be available across the entire company. One example of this might be products, as products would be referenced on multiple entities across the organization. The quote / orders (etc) that they are referenced on would be user / team owned. But the actual products would remain open to the entire organization.

User or team owned records have a greater number of ownership options available. As shown in the chart below;

As the name suggests user / team ownership means the entity can be owned by a user or team. Examples of this would include contacts and accounts. Below you can see a list of accounts, notice how each one has an owner. Typically core entities in the system that require control using security roles will have user / team ownership.

When defined for this type of ownership an additional owner field is created that will hold the owner for each record. (ownerid) When an entity is defined as user / team owned options in security roles will include none, user owned, parent / child business unit, business unit and organization.

Entity Properties / Settings

Each entity has numerous properties or settings, some of which can only be set as the entity is created. (Such as the entity ownership approach.) Others properties can be set after creation but once defined cannot be disabled. (For example, Notes.) Some properties can be enabled / disabled at will. (Such as the option to allow quick create.)

For the MB 200 exam it may be important that you become familiar with all of the main settings on an entity and appreciate which can and can’t be disabled. It will be productive preparation exercise to create some entities and experiment with what happens when you try to enable / disable various properties.

Below you can see I have opened an entity in my organization, I can use the settings option to view the various properties of the entity. These are grouped under several headings including entity type and ownership, collaboration etc.

As an example, below you can see that I have expanded the collaboration settings section. Here we can control various collaboration settings such as enabling for document management. Importantly notice that some options can not be disabled once enabled.

Settings that cannot be disabled once enabled include;

• Entity type
• Entity Ownership
• Feedback
• Activity task
• Connections
• Send email to entity
• Queues
• Notes

Tip:
Whilst I encourage you to use the newer make.powerapps.com interface as much as possible, try swapping to the classic view to also view the entity properties. At the time of creating these notes some properties existed in the classic view which have yet to be replicated in the newer interface.

Here is a quick summary of some things you might need to be aware of;

• The entity name cannot be changed, and will be prefixed with the publisher prefix.
• Display name and plural name can be changed.
• Ownership can be “User or Team” or Organization. Once set it cannot be changed.
• All entities will have a primary field, called “name” by default but this can be changed. (Whilst creating the entity.) The primary field can only have a type of “Single Line of Text”. It will default to a length of 100 but this can be changed. (Note: The primary field is not the database primary key; it does not have to include a unique value. Behind the scenes each record has a GUID which is an automatically created primary key.)
• On creation entities can be defined as being an activity entity. Custom activity entities can optionally be displayed in the activity menus. All activity entities will be by implication User or Team owned. All activities share a common set of privileges.
• Having saved an entity, the following properties are read-only, meaning they can only be defined as you create an entity,
  • Name
  • Ownership
  • Define as an activity entity
    • Display in activity menus
• Once enabled on an entity the following properties cannot be disabled;
  • Business process flows
  • Feedback
  • Notes
  • Activities
  • Connections
  • Sending email
  • Queues
• Notes, activities and connections are enabled by default when a custom entity is created. But they can be disabled on create.
• Document management, access teams, allowing quick create are all examples of properties that can be turned on and off.
• Enable for mobile, allows you enable the entity for mobile and if you require mobile offline. Plus you can configure download filters to drive how much data will be available offline.

Note: These bullet points are not an exhaustive list! A good percentage of our revision time should focus on gaining a deep understanding of entities.

Managed Properties

The managed properties option lets you define how various properties can be managed if the entity is included as part of a managed solution. You may for example, restrict creation of new forms but allow creation of views. It is worth reviewing the options available here to appreciate what can be locked down.

If is also possible to select the “can be customized” option. Setting this to false would mean no properties can be customized if this entity becomes part of a managed solution.

Tip:
Notice I am using the classic entity management below!

Update ICONS

You can use the update icons option to assign custom icons to the entity if required. Notice that two icon files are required with specific sizes, 16×16 and 32×32 pixels

If you don’t set these custom entities get a “cog” icon by default.

Note: Icons will need to exist as web resources.

System v Custom Entities

Dynamics 365 contains many system entities such as account, contact, incident, opportunity, quote, order, invoice and so on. Often when we decide to make a customization the best option is to use an existing system entity. As much of the functionality you might wish to develop is then delivered using out of the box features.

Often terminology is all that is blocking the use of a system entity. One common example is the use of the term “Account”, as many companies might use a different term such as Organization, Partner, Client etc. When this happens it is often best to still use the account entity but alter the display name to fit whatever terminology is appropriate to a given situation.

Tip: If you change the display name of a system entity you may wish to also rename views and edit any system messages. (Using the messages option whilst customizing the entity.)

Keep in mind that some entities have a very close relationship to wider system functionality. For example, marketing lists can only contain accounts, contacts or leads. So if you want to leverage the inbuilt marketing lists you will need to hold the organisations / people you engage with in these system entities.

As a general rule it is always better to use an existing system entity in preference to a custom entity. (But as with all “rules” you will no doubt find exceptions to this rule!)

You do need to be aware that there are some limitations on customizing system entities.

On occasions when you wish to create something which is really quite different to any feature provided by a system entity creating a new custom entity provides you with ultimate flexibility.

System entities will already be included in the sample security roles that ship with Dynamics 365. As you create custom entities they will show in the custom entities tab of the security roles. By default, when you create a custom entity only the system administrator will have access to the entity. So you will always need to add a custom entity to a least one security role. (And also include the altered security roles in your solution.)

Entity Controls

We can also define a number of controls on entities and fields that allow us to define how controls appear on forms within the web application and mobile applications. For example, we can decide to enable editable grids.

When editable grids first launched I created a details post explaining how to configure them, you can see that here.

Deleting Entities

You need know the following things about deleting entities;

• You cannot delete system entities. (Although you can “hide” them by creative use of security roles or amendments to the site map / apps.)
• Custom entities can be deleted.
• You cannot delete a custom entity if other entities have dependencies on it. For example a look up to that entity. You would need to remove the dependencies before attempting the delete!
• If the entity you wish to remove is part of a managed solution you will not be able to remove it directly. You would need to remove the entire managed solution.
• When we remove an entity its definition is removed along with all the data records.

Hopefully this post has given you a good overview of the items you’ll need to revise around entities. However entities are a big subject and I have only scratched the surface here. Later posts will build on this introduction, additionally I encourage you to get as much hands on experience as possible in creating and maintaining entities. In particular become familiar with which features are available in make.powerapps.com and which are only possible in the classic interface. Enjoy.