Relationships are a powerful concept in CRM letting users easily relate relevant records to each other. For example an Account may have related leads, cases, activities, opportunities, contacts etc… Relationships also define cascading behavior of related records when their parent record is shared, re-assigned, re-parented, deleted or merged with another record. For example if an account is assigned to a new user, all related leads, cases, opportunities, activities also get assigned to the new user. The cascading behavior in this example is by default set to Cascade All.
There are many instances where this default cascading behavior may not sit well with the business practice at a certain organization. For example when an account is assigned to a new sales representative, it may not desirable to share the data from already closed opportunities that were generated by the previous account owner. Even worse activities (such as appointments) that were created and initiated by the previous owner now appear as done so by the newly assigned rep. There are also team selling scenarios where the account itself may be owned by one person (say the Sales Manager) but individual activities (phone-call, appointment, email….) may be owned by the members of their team. If the sales manager assigns the account to one of their sales associate (or another sales manager), all the existing activities should remain assigned to their existing owners (and not get assigned to the new sales associate).
Our customers have been frustrated by the default behavior and even more so by not being able to find an appropriate work-around. We wanted to address this limitation in CRM 3.0 and began asking questions on our newsgroup for the desirable behavior. Our initial design was to be able to provide the end-user such as a Sales Manager, or a Sales Rep themselves to be able to change the behavior of how related records got reassigned, shared, deleted or re-parented each time that they chose to reassign/share/delete or re-parent a record. As part of our feature design process, we invited comments both from our internal design team in addition to from our newsgroup user community. It became apparent that our initial design would have been too cumbersome for most of the CRM users and an overkill to what typically transpires in real-life business practices. The feedback helped us rethink the whole feature overall again and we therefore adopted the current design where we enable the changes to be more prescriptive i.e. part of the relationship model itself instead of each record instance.
An administrator or system customizer (default security roles that have permission to customize relationships) now may easily customize the cascading behavior of related records through the entity customization forms (Settings->Customization->[entity]->Relationships->[Primary entity – Related Entity Relationship]). There are different types of relationships – System, Parental, Referential, Referential w/ Restricted Delete. System relationships such as parent contact or account for an account etc… are not available for customization and may or may not cascade – their behavior is system defined and cannot be altered to preserve the default semantics of CRM application. Referential relationships do not cascade and therefore do not need any customization for altering cascading behavior of related records. Parental relationships are customizable for cascading behavior of related records.
To modify the cascading behavior of related opportunities for accounts for example, they open the account to opportunity relationship that is marked as a parental relationship. See the image below for this form. Relationship Behavior can be changed from Parental to Configurable Cascading and this action enables the settings for Assign, Share, Unshare, and Re-parent operations to be customizable individually. Delete and Merge operations are always protected from any changes to preserve overall system integrity and application semantics.
Based on customer feedback, and our generalization of common business practices, we decided to offer some options on cascading behavior – these include ability to cascade the selected operation (Assign, Share, Unshare, Re-parent)
1. For all related records (default)
2. for only records that are currently active (i.e. closed / inactive records are left as-is)
3. For only records that are owned by the same user (i.e. for Assign operation, records assigned to other users remained assigned to them), and
4. For no records at all.
We believe that with this ability to reconfigure the default cascading behavior for related records, we have now provided a powerful customization feature that enables customers to model their business practices more accurately with-in CRM.
The feature design also helped us reinforce our commitment to listening to our customers closely during the development cycle. We (Ok, I personally) frequently design the feature behind closed doors by internalizing customer requests one way and then forget to go back and validate our interpretations with the customers. I am glad that our customers helped us design this feature more in tune with their needs than our whims.