• "Book - Microsoft Dynamics CRM 2011 - Customization & Configuration ... - Chapter 5"
  Published by Neil Benson (Packt Publishing)
  http://my.safaribooksonline.com/book/certification/9781849685801/microsoft-dynamics-crm-2011-customization-and-configuration-mb2-866-certification/ch05_html

To manage your organization's processes in Microsoft Dynamics CRM, you'll need to create relationships between the entities it manages during those processes.
Using Microsoft Dynamics CRM 2011, you can create two different types of supported entity relationships.

Types of entity relationships

Using the customization features of Microsoft Dynamics CRM 2011, we can define two types of entity relationships:

• 1:N (one-to-many): For example, a customer can have many opportunitties, and an opportunities can be associated with one customer.
• N:N (many-to-many): For example, a contact can be member of many marketing lists, and marketing lits can have many contacts as members.

Unsupported relationship types

there are two types of entity relationships that are not supported by Microsoft Dynamics CRM 2011:

• 1:1 (one-to-one): These types of relationships are useful in scenarios where one type of record becomes another type of record, for example, where a prospect becomes a customer or a student becomes a graduate. In Microsoft Dynamics CRM 2011, there are limited numbers of standard 1:1 relationships - for example, a lead can become an account and a queue item is associated with one case or activity record. You cannot create custom 1:1 relationship without custom development.
• Polymorphic relationships: These types of relationships are useful when the primary record in a relationship could be one of several different entity types. For example, a customer complaint could be about a case, invoice, or order. In Microsoft Dynamics CRM 2011, there are one or two standard polymorphic relationships - for example, the customer of an opportunity can be account or a contact, and the regarding record of an activity can be one of many different entities. You cannot create a custom polymorphic relationship.

1:N relationships

In a 1:N relationship, a primary record can be associated with zero or more related records, and the related records can be associated with one primary record.

N:1 relationships

We create a custom 1:N relationship in Microsoft Dynamics CRM 2011 from the primary entity by specifying the related entity type. We can also create a custom N:1 relationship from the related entity by specifying the primary entity type. So, the 1:N and N:1 are created from a different starting point, but are otherwise the same. We can also create custom N:1 relationships by creating a lookup field on a related entity.

For example, in Microsoft Dynamics CRM 2011, an account can have many contacts associated with it. Each contact can have a parent account. From the point of view of the account, this is 1:N relationship with contacts, and from the point of view of the contact, this is a N:1 relationship with accounts.

Relationship behaviors

When you carry out certain actions on a primary record, the related record may also be affected depending on the defined relationship behavior between the two entities. The important actions are as follows:
 

• Assign: Changing the owner to another user or team.
• Share: Sharing the record with another user or team.
• Unshare: Revoking the sharing with another user or team.
•  Reparent: Associating the record with a new parent record, for example changing the customer of a case.
• Delete: Deleting the record.
• Merge: Merging two records (for contacts and accounts).
  
  

All other actions - such as activating and deactivating the primary record - have no effect on any related records.

There are four relationship behaviors types as follows:

1. Parental: Any action taken on the primary record is also taken on all related records. For example, if you delete the primary record, all the related records are also deleted. In a parental relationship, the primary and related records are often called the parent and child records.
2. Referential: Any action taken on the primary record does not affect any related records. If you delete the primary record, the link to that record is removed from the related records.
3. Referential, Restrict Delete: Any action taken on the primary record does not affect any related records and you cannot delete the primary record while it has one or more related records.
4. Configurable Cascading: You can define whether actions taken on the primary record are cascaded to the related records or not. The available options are as follows:
   1. Cascade All: Any action taken on the primary record is also taken on all related records.
   2. Cascade Active: Any action taken on the primary record is also taken on all active related records - inactive related records are not affected.
   3. Cascade User-Owned: Any action taken on the primary record is also taken on all related records owned by the same user that owns the primary record.
   4. Cascade None: Any action taken on the primary record does not affect any related records.
   5. Remove Link: This option also only applies to the Delete action and removes the link between the primary record and all related records.
   6. Restrict: This option applies only to the Delete action and prevents a primary record being deleted when it has one or more related records.
      
      

There are some rules and restrictions on entity relationships in Microsoft Dynamics CRM 2011:

• An entity can have multiple relationships with another entity. Each relationship schema name must be unique.
• To avoid system entities being parented by the custom entities, a custom entity should not be the primary entity in a relationship with a related system entity where the relationship  behavior is Parental, or where the relationship behavior is Configurable Cascading and one of the options is set to Cascade All, Cascade Active, or Cascade User-Owned.
• To avoid the multi-parental relationships, an entity can be the related entity in one relationship where the relationship behavior is Parental, or where the relationship behavior is Configurable Cascading and one of the options is set to Cascade All, Cascade Active, or Cascade User-Owned.
• No system entities have a Configurable Cascading entity relationship behavior.
• Where two system entities have a Parental relationship behavior, you can modify the behavior to Configurable Cascading, but not to Referential, Restrict Delete. 
• The System relationship behavior is a special behavior type reserved for some system entity relationships and it cannot be modified or used in the custom relationships.
• Changes to the user interface elements of relationships – such as the display name of the lookup field  - must be published before they are applied to the system but schema changes – such as the relationship behavior  - do not need to be published.

N:N relationships

In an N:N relationships, a record of one entity can be associated with zero or more records of a second entity, and records of the second entity can be associated with zero or more records of the first entity.

Native and manual N:N relationship types

When an N:N relationship exists between two entities, an intersection entity stores the identifiers of each related record.

Self-referential relationships

A self-referential relationship is a relationship between an entity and itself. There are two types of self-referential relationships:

1. Self-referential 1:N relationships
2. Self-referential N:N relationships

Self-referential 1:N relationships

Self-referential 1:N relationships are useful for representing the hierarchical associations between the records, for example, a master order with related sub-orders.

Self-referential 1:N relationships can have a parental relationship behavior. If the relationship behavior is parental, any assign, share/unshare, reparent, delete, or merge action applied to the parent record will also be applied to all its child records.

A self-referential relationship cannot be used to create either direct or indirect circular relationships where the primary record is related to itself or any record in its own hierarchy.

To create a self-referential 1:N relationship, follow the procedure to create 1:N relationship and specify the primary entity to be the same entity as the related entity.

Self-referential N:N relationships

Self-referential N:N relationships are useful for representing the loose associations between records, for example, cases linked to other cases where the root cause of all cases is the same.

Mappings

Entity relationships field mappings reduce the data entry required when new records are created from within the context of a primary record.

For example, when you create a new contact from the Associated Contacts view on Account form, some of the data from the account – such as address and phone numbers – is copied to similar fields on the new contact record. Mappings in the account-to-contact entity relationship make this possible.

Field values from the primary record are only copied to the related record when the related record is initially created. If the fields in the primary record are later modified, the changes are not copied to the related records.

Requirements for Mapping

Some requirements must be met before two fields can be mapped:

• Both fields must have the same datatype and format.
• If the fields are text fields, the target field length must be equal to or longer than the source field length.
• If the fields are option sets, the integer value for the source option should match the integer value for the target option, otherwise the option set values will appear to map incorrectly.
• A target field can only be mapped to one source field. If you want to modify the mapping, delete the existing mapping and create a new mapping.
• A source field can be mapped to several target fields.
• Only the editable fields that are published on the form of the source entity can be mapped.