In Microsoft Dynamics CRM the behaviors assigned within entity relationships describe what actions should cascade down to related records. For example, if you re-assign a contact record, what should happen to any opportunities where that contact represents the potential customer? For certain entity relationships, you can control this by changing the cascading behavior.
Certain system entity relationships for the Account and Contact entities appear to have conflicting cascading relationship definitions. For example, there are two entity relationships between the Contact entity and the Opportunity entity.
When you open each entity relationship, you can see details about how they are configured:
If you assign a contact that is associated with an opportunity, which behavior should you expect?
The correct answer is Cascade All. The relationship that references the contactid is the only one that matters. Why? If you look at the definition of the Opportunity entity you will see that there is no contactid attribute.
This is because there is no actual “Customer” entity. In Microsoft Dynamics CRM, the Customer is a virtual composite entity where either an account or a contact can be a valid customer. When the Potential Customer lookup field for an Opportunity record is set, the customerid value is set. Yet when the record is actually saved in the database, the database table column where that value is saved is either the accountid or contactid column, depending on the type of customer. There is no customerid column in the database table for opportunities.
While this may seem confusing at first, just keep in mind that a customer is always an account or a contact. If you see an entity relationship that includes the word ”Customer” – remember to look for two other entity relationships for account and contact. Those are the relationships that will actually control what behavior you can expect for cascading actions.
In addition, the Customer entity relationships always have the Type of Behavior set to System and the cascading behaviors are the least restrictive, usually Cascade None, or, in the case of the Delete action, Remove Link. Some of the actual relationship behaviors for account and contact entity relationships are customizable.
The following table shows the entity relationships that exhibit this behavior.