Entity customizations
Part 5 of "11 things to know about customization"
Published: March 26, 2007
Microsoft Dynamics CRM uses the word “entity” to refer to the structures used to store and manage data. Conceptually, an entity is approximately comparable to a database table, except that it includes more than the table. An entity includes the form, views, and behavior of that entity in the system. Entities correspond to the types of records Microsoft Dynamics CRM manages.
In addition to the default system entities, you can create custom entities. The ability to add custom entities is a powerful way to extend Microsoft Dynamics CRM functionality and does not require that you write code. Microsoft Dynamics CRM MVP John O’Donnell (www.crowecrm.com) points out that the ability to create new entities in Microsoft Dynamics CRM lets an organization create new data structures for their industry. For example, a realtor might add a new entity called Property to store all the houses they are selling.
On This Page
Attributes
Each field in an entity form represents an attribute of the entity. You add new fields to the entity form by exposing an entity attribute on the form. You can add custom attributes to system entities to supplement the system attributes that are provided. For most of the system entities, there are more attributes than fields that you see on the form. Before you create a new attribute, check whether there is an existing system attribute that fits your needs.
When you create a new custom entity, you must add any additional attributes that you will need. The table below shows the types of attributes you can add.
|
nvarchar | This kind of field stores text. You can apply some formatting options to control how the text appears and behaves. These are as follows: Text, Text area, E-mail, URL, or Ticker Symbol, and the maximum length. The maximum length is 4000 characters. |
picklist | A HTML select control, sometimes known as a ‘drop-down list’ or ‘combo-box’. You define the choices that will be displayed in the list. |
bit | A field that stores a value of true or false. In the form, you can decide whether to show this attribute as radio buttons, a check box, or a picklist. |
int | A field that stores an integer – a number without a decimal point. You must specify the format of the field, and the minimum and maximum values. |
float | A number that uses a decimal. You can set the number of decimal places to display, and the minimum and maximum values. |
money | This is the same as a float, except it will be displayed on the form with a currency symbol next to it. |
ntext | A field to store longer text, also known as a text box. These fields can store a maximum of 5000 characters. |
datetime | When these fields are displayed on a form, they include a field where the date is visible and can be edited. They also include a calendar control to help locate a specific date. You can decide whether to include a specific time. |
Field Constraints
When you add an attribute, you can also set whether the field that represents that attribute will be required for users to enter data. You have three choices:
| • | Business required. The user must enter data in this field before they can save a record. This field will have a red label. |
| • | Business recommended. This does not require the user to enter data. It gives the field a blue label and will make the field appear in a “Quick Create” form. This form is used when users have to quickly create a record with only the important fields. |
| • | No constraint. The default setting. A regular field that has no special constraints. |
Relationships
When you create a custom entity, you probably want to relate it to another entity. A ”stand-alone” entity is not very useful because it is not connected to any other data in the system. You relate entities by adding a relationship.
Adding relationships may be confusing if you are not already familiar with some theory behind relational data structures. It is useful if you already know about primary keys and foreign keys – but it is not necessary to create a relationship in Microsoft Dynamics CRM.
You add a relationship from an entity form. As shown in Figure 1, you have the choice between New 1-to-Many Relationship and New Many-to-1 Relationship. Which one should you click? It depends on the outcome you want.
Figure 1: Adding relationships to a custom entity
In each relationship, there is a primary and related entity. The related entity has a relationship attribute that you use to associate it with the primary entity.
| • | Select New 1-to-Many Relationship when you want the current entity to be the primary entity. |
| • | Select New Many-to-1 Relationship when you want the current entity to be the related entity. |
When the relationship attribute is added to the related entity form it will be a ‘lookup’ field. You use that field to find another record from the primary entity and relate that record to the one that you are currently editing.
Figure 2 shows a custom Department entity record with an Account lookup field – the result of adding a new Many-to-1 relationship on the Department entity. This Department entity also has a 1-to-Many relationship with the Contact entity so that you see Contacts in the Navigation pane on the left. Clicking Contacts will show a list of any contacts associated with this department.
Figure 2: Custom Department record that displays the account lookup field
Figure 3 shows how the Account form has changed because of the Account-Department relationship. This same relationship could be created from the Account entity if you chose to create a new 1-to-Many Relationship.
Figure 3: Department records in the account form
Cascading behaviors
The relationships you create affect the integrity of data. For example, if you create a custom entity with a relationship to the Account entity, you can create a record using that custom entity that is related to an account record. What do you want to occur if that account is deactivated, deleted, or reassigned? Cascading behaviors describe the actions that are performed in response to an event like this.
In most cases, you want to do something if the account is deleted, because the related records could become ”orphaned records” if they aren’t related to another account. People might be unable to find the record. In most cases, the related record is not important without the primary record. Therefore, you might as well delete it. However, Microsoft Dynamics CRM doesn’t make that decision for you. You decide what is right for your business.
Part of configuring a relationship is deciding what type of behaviors you want for specific actions. In some organizations, if an account is re-assigned, you would want all open sales opportunities to be reassigned too. In other businesses, you wouldn’t want this. You can define the appropriate behavior using the relationship behavior part of the relationship.
An important consideration: When any actions cascade in a relationship, that relationship is called a “Parental Relationship”. This is important to remember because it is a factor in some limitations of the kind of relationships you can create. When no actions cascade the relationship is considered a “Referential Relationship”.
When you define the relationship, you can select from some predefined groupings of actions. These are known as “Types of Behaviors”. These are as follows:
| • | Parental |
| • | Referential |
| • | Referential, Restrict Delete |
| • | Configurable Cascading |
The important thing to remember is that configurable cascading gives you more control over exactly which actions will cascade – but as long as one action cascades – the relationship is considered “Parental” with regard to the limitations for creating relationships. So let’s talk about those limitations.
Relationship limitations
There are five limitations to be aware of when you create relationships:
1. | When you create a relationship at least one of the entities must be a custom entity. You cannot create relationships between two out-of-the-box Microsoft Dynamics CRM entities. These are also known as “system entities”. These entities already have all possible entity relationships defined. |
2. | A custom entity cannot be the parent of a system entity. This means that you can create a referential relationship where a system entity has a lookup field to link to a custom entity – but there cannot be any cascading behaviors that affect the system entity. |
3. | You cannot create more than one relationship between any two entities. For example, you cannot create two new relationships in order to create ”Primary Contact” and ”Secondary Contact” lookup fields on an entity. |
4. | You cannot create a self-referential relationship. For example, you cannot create an “Associated Contact” lookup on the Contact entity. |
5. | You cannot create a relationship to the virtual customer entity. Case, Opportunity, Quote, and other Microsoft CRM entities have relationships that can exist for either Contact or Account entities. These two entities represent customers. Together they are also known as a “virtual customer” entity. You can create relationships to Contact and Account separately – but you cannot create a relationship exactly like the ones in some Microsoft Dynamics CRM system entities like Case, Opportunity, or Quote. |
Although Microsoft Dynamics CRM 3.0 does not let you create Many-to-Many relationships, one technique to simulate them is by creating an intersect entity. An intersect entity has a 1-to-Many relationship with one entity, and a Many-to-1 relationship with the other entity. Together this creates a type of Many-to-Many relationship. However, it does not provide the best user experience because users have to open the intersect entity to make the connection.
Mapping
The 1-to-Many side of a relationship presents a list of the associated entities. Users can create new instances of the associated entity from this view when they click the New button. It is much easier to create new records in this manner, because data from the related record is automatically mapped to the new record, streamlining data entry. You can control which fields are populated with data from the related entity by configuring mapping within the relationship.
It is important not to misunderstand mapping. Microsoft Dynamics CRM does this mapping only on the creation of a new record. It does not maintain the data in the relationship after the record is saved. If a value in the related record changes, the mapped data in the other record will stay as it was when the record was created.
