Recently, we’ve had a few client users report seeing a large number of new appointments and tasks created in their Outlook profile which did not belong to them. The user had not created these Outlook activities; neither had the user shared a relationship with them. Specifically, these appointments appear to have been synchronized from Microsoft CRM into their Outlook profile. The user’s CRM for Outlook profile is set synchronize appointments, tasks, and phone calls that they are the owner of – configuration settings that were not out of the ordinary.
What could have caused these activities to synchronize?
The problem may have been caused by cascading behavior actions in the CRM, between two or more related entities. For example, an action taken at the contact record affected activities that were related to this contact. One way to check if cascading actions may have been the cause is to review the ‘Last Modified Date’ and ‘Last Modified By’ values between related and parental records – the values in these fields will be same. To find these details, click the Microsoft Orb icon in the top-left window corner and select Properties on each record window.
What are cascading behaviors?
Cascading behaviors define what happens to related records, when a particular action is taken at its parent record. For example, consider contact records that link up to an Account (schema name: cbr_account). In the case of an owner re-assignment at the account level, all related contacts (i.e., contacts that link up to the account) will be re-assigned to the same owner as the account. It is also worth noting that a cascading behavior action can affect related records at multiple levels (e.g., activities that link up to contacts which link up to an account). This is the concept of cascading behaviors.
You will find cascading behaviors by navigating to Settings -> Customizations -> Customize entities -> Entity name -> Relationships (1:N) or (N:1), and opening the relationship record.
The common cascading behaviors are:
- Parental – actions taken against the primary entity apply to related entities
- Referential – actions taken against the primary entity only apply to that entity, and not against any of the related entities.
- Configurable Cascading – define which actions are allowed to cascade, and how.
For Configurable Cascading, you choose which actions cascade. These actions are: Delete, Assign, Reparent, Share, and Unshare. You will also specify rules for each of these actions types. The rules are:
- Cascade All – action performed at the parent record affects its related record (similar to Parental).
- Cascade Active – same as Cascade All, except cascade only those records which are active.
- Cascade User Owned – action performed at the parent record affect only related records that match the owner of the parent record
Cascade None – action performed at the parent record does not affect the related record (similar to Referential)
Putting it all together
At one of our client’s environment, there was a parental relationship between activity types (e-mail activities, tasks, appointments, phone calls, letters, and faxes) and contacts (N:1). There was also a parental relationship between contact’s and a custom object, Account (N:1). One day, Mary, a user re-assigned the owner of an account record from Rosie to Stephanie. At the moment the account was re-assigned, the owner of all contact’s that were related to this account assumed the new owner, Stephanie. All activity type record related to contact’s that belonged to this account also took the ownership of Stephanie. Stephanie will now synchronize many more appointments and tasks into her Outlook, because she is now the new owner of these re-assigned activities.
What can be done to correct this problem?
- First, determine if the issue was caused as a result of cascading behaviors (i.e., review the ‘Last Modified On/Date’ fields).
- If the information appears to point to a cascading effect, determine at what level the cascading effect may have been started. This is not always easy to find, if the action is not based on re-assignment.
- Determine at what level cascading should be changed between entities. Planning this step is very important as the cascading changes can impact other levels.
- Change the cascading relationship behaviors and publish your customizations
You may find it helpful to speak to, and work with Salentica (for SEA clients, contact your account manager) to determine the best course of action in such cases.
