Primary fields as lookup values
A lookup field enables your users to specify the primary record of a related record. Microsoft Dynamics CRM displays the primary field value of the primary record in the lookup field, but stores the global unique identifier (GUID) of the primary record in the database.
For example, the primary field of the User entity is the Full Name field. When a user is the owner of a record, the system displays the name of the user in the Owner lookup field on the related record, but stores the GUID of the user record in the Owner field in the CRM database.
When you carry out certain actions on a primary record, the related records 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 behavior types as follows:
• 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.
• Referential: Any action taken on the primary record does not affect anyrelated records. If you delete the primary record, the link to that record is removed from the related records.
• 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.
• 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:
°° Cascade All: Any action taken on the primary record is also taken on all related records.
°° Cascade Active: Any action taken on the primary record is also taken on all active related records—inactive related records are not affected.
°° 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.
°° Cascade None: Any action taken on the primary record does not affect any related records.
°° Remove Link: This option also only applies to the Delete action and removes the link between the primary record and all related records.
°° Restrict: This option applies only to the Delete action and prevents a primary record being deleted when it has one or more related records.
Example of relationship behaviors in an action
The Opportunity entity has the entity relationships and relationship behaviors as described in the following table:
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 only 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.