30 day trial
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), and4. 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.
I agree, I only found out this was a serious issue for us when users re-assigned contact records to different people for "support" reasons and not sales reasons. In doing so it re-assignes all activities, orders, and everything to that person as the owner. Especially completed activities!!! the owner should always be the person who entered the thing, always.....now i have to go back and hand fix 360 orders on a new implimentation so that the owner is the actual sales rep instead of who the contact was re-assigned to....god help us.
I admit it: I’m a bear of little brain. In my first post I wrote about my favorite feature of CRM 3.0
I’ve seen this question come up on the newsgroups, as well as internally. A user will have access to
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 relate
When I created a Workflow to re-assign some Accounts, it cascaded this change to all the activities. That was a problem, but it was also my fault for not doing enough research. However when an Account is manually re-assigned by a user, this does not cascade to all of the activities. That seems like a bug to me.
I have created two custom entities and am attempting to cascade sharing between them. It seems that no matter what relationship behaviour (i.e. either 'parental', or 'configurable cascading' with different values for the actions) i try the records will not cascade when I share the primary entity (nor will they cascade if I share the related entity. I have tried every possibility I can think of).
I can toggle the delete relationship behaviour when selecting the configurable cascading option and this works as specified (i.e. either cascade all or remove link), so I am at a loss as to what I can do to try and get this working.
If anyone has had this problem I would appreciate any help.
PingBack from http://topalternativedating.info/story.php?id=4875