NEIL PARKHURST

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

It is very important to realize that customizing entities will be very much at the heart of the customization and configuration exam. So spending a good amount of time actually creating and customizing entities is very important. Please only use these notes as revision pointers! You should (and must) become very familiar with actually customizing entities. Just knowing the theory won’t be enough!

Entities are at the center of anything and everything we do concerned with customizing 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.

Entity Types

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

• System Entities
  • Built-in entities which are created when a new CRM 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 with 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.

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.

Note:
system activity entities or custom activities are always user or team owned.

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

Each entity has numerous properties, 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 MB2-716 exam it will be important that you become familiar with all of the main properties 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 highlighted a number of entity properties that cannot be changed after the entity is created.

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.
• You can optionally enable entities for the interactive service hub and you can disable this option if required. By default an custom entities are not enabled for the interactive service hub.
• Each entity can be given a colour; all custom entities will default to green. But this can be changed.
• All entities will have a primary field, called “name” by default but this can be changed. 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.
• An entity can be shown in none, one or multiple areas in CRM. Out of the box the areas include sales, service, marketing, settings and help center. You can only change this option for custom entities it is not possible to change the display area for system entities.
• 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.
• Properties are grouped under several headings; these include;
  • Process – allows enabling an entity for business processes.
  • Communication & Collaboration – Collaboration options include sending emails, access teams, queues etc.
  • Data Services – data featuring include auditing and duplicate detection etc.
  • Outlook & Mobile – Allows an entity to be enabled for mobile and phone access.
  • Help

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.

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 Organisation, 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 features 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. Such as you can’t change their icons or their display area.

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 detaisl post explaining how to configure them, you can see that here.

Deleting Entities

You may 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.)
• 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. If you have previously studies for the MB2-712 exam you will find much commonality with the MB2-716 exam! But still make sure you fully understand some of the new features such as editable grids.