Unfortunately, using the out-of-the-box functionality, there is no way to modify the Resolve Case form.  However, the Status Reason picklist values can be changed from the Attributes of the Incident entity.

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.

On the Marketing List, however, you may have notice that you cannot add columns to the marketing list members view.  Use the workaround below to enable you to customize the members view using a direct URL link.  Replace the http://crm/ portion with your CRM server name.

Member type: Accounts

http://crm/tools/vieweditor/viewManager.aspx?id={51DE84DD-732F-440F-A506-26123A19AB50}

Member type: Contacts

http://crm/tools/vieweditor/viewManager.aspx?id={2F0D0EDE-D356-4B1E-83BD-E978F10E3EEB}

Member type: Leads

http://crm/tools/vieweditor/viewManager.aspx?id={FC1B8995-4E44-4D65-99BE-1E945953564C}

When finished, remember to publish all customizations.