Welcome to my next post aimed at helping people prepare for the MB2-712 exam (Microsoft Dynamics CRM 2016 Customization and Configuration). In this post I’m going to continue my series by looking at entities. Initially by giving an overview of entity customization and then diving a little deeper into some of the options around entity properties etc.

It is very important to realise 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 – An Overview

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

Each CRM entity can be owned by the organisation or a user, this in turn helps drive what security options are appropriate for each entity.

Entities have many properties which drive their behaviour, examples include being enabled for document management, having notes, supporting related activities, allowing connections or being enabled for mobile access. In this and future posts I will spend time covering many of these properties.

It is important to remember that any changes to entities will need to be published to make them show in the live application. You can use the publish option to publish the entity you are working on or use the “publish all” to publish everything. (Including changes being created by other developers!)

In the following sections I will expand on these concepts.

Entity Assets

Each entity is made up of multiple assets, we touched on these slightly when I covered the concepts of solutions, as 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.

The most obvious 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 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 organisation is created.
  • Most can be modified, such as account, contact etc.
  • Some system entities can’t be customized.
  • Can never be deleted.
  • When considering solutions, cannot be locked down by a solution.
• Custom Entities
  
  • Can be created by system customizers.
  • Can also be created when imported managed or unmanaged solutions.
  • Can be changed. (Unless locked down with managed properties.)
  • Can be deleted.
• 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 Ownership

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

Organization owned entities are available to the whole or organization (or not) dependant 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.

As the name suggests user / team ownership means the entity can be owned by a user or team. When defined for this type of ownership an additional owner field is created that will hold the owner for each record. 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-712 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.

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 centre. 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.
• 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

CRM 2016 contains many system entities such as account, contact, incident, opportunity, quote, order, invoice and so on. Often when we decide to make a CRM 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 CRM. 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.)

Hopefully this post has given you a flavour for the topics you need to revise connected with entities in the MB2-712 exam. In my next post I will continue this theme and start to look at how to customize fields within the entity.
J