Activity Management Enhancements in Dynamics 365 (v8.2)

Whenever a new version of Dynamics CRM and now Dynamics 365 (the XRM part) are released, the first thing you should review is the “what’s new” documentation that Microsoft produces for three different audiences: users, admins/customizers and developers. For the “December 2016 update for Dynamics 365” a.k.a version 8.2 of what used to be called CRM, these articles can be found from the following links:

• Dynamics 365 Help & Training: What’s new
• What’s new for administrators and customizers in Microsoft Dynamics 365
• What’s new for developers: Microsoft Dynamics 365

As always, there’s way more goodies in there that a single blog article could ever hope to cover in meaningful level of detail. One area that deserves a mention in terms of the core XRM platform enhancements is the way activities can now be presented in the UI, so let’s focus on those in this here post.

Display the associated activities of the related entities

If you’ve happened to read my ancient CRM 2011 era blog post about how subgrids ain’t what associated views used to be, then the concept of activity rollup may be familiar to you. The way Dynamics CRM has worked up to this point is that for out-of-the-box core entities like Account and Opportunity the activities from under the child entity were presented also under the parent entity’s Associated Activities View. If you created a custom entity under the Account, though, then none of the activities linked to it would show up in the rollup view. A major inconvenience for any XRM scenarios where you then had to instruct the users not to track their activities against any of the child entity records but rather put them all to the Account level.

In v8.2 this limitation has now been addressed by the product team:

“We added a new flag called Rollup View in the customization user interface, on the Relationship Behavior form. It lets customizers indicate that associated activities of the related entity should be included in the Activity Associated View for the primary entity.”

Woo-hoo! Let’s go and try this one out in an example scenario with a custom entity called “Account Plan” that we’ve linked to the standard Account entity via N:1 relationship. Meaning: there can be several Account Plans (per year, for example) for a single Account. Being the “plan” and all, you’d find it pretty natural to track tasks and other upcoming activities against this record, but also would probably prefer to have access to them from under the parent Account of this plan.

When we open up the relationship configuration screen and have a look at the Relationship Behavior section, we find our usual list of actions where cascading behavior can be configured. Down at the bottom there’s a new option: Rollup View. This is where the magic will happen for activity rollup between the two entities. (Note: if the field is disabled, make sure your entity is enabled for activities before trying to enable the Rollup View.)

With the Rollup View behavior set to “Cascade All”, we can now go and do some activity entry on the Account Plan form. Let’s use the Social Pane to add some tasks that are set regarding this particular plan. Normally this would be the only place where we’d see them (aside from the owner’s My Activities view and their task list synced to Outlook, of course), but thanks to our cascading relationship behavior this will no longer be the case. Let’s navigate up in the hierarchy towards the Account record.

Now, in addition to the activities that have been either directly set regarding the Account or one of the built-in roll-u enabled child entities, we also see those activities created from the Account Plan form listed in the Social Pane of the Account record. A tiny step towards the mythical “Customer 360”, but a major improvement nonetheless for ensuring the complete communication history for a particular customer account is easily accessible for the Dynamics 365 end user. In case you were wondering: yes, these child entity activities also roll up the account hierarchy, so a global group’s top account may end up having a BIG list of emails in its Social Pane.

As for another follow-up question related to the article from five years ago: no, the activity subgrid still won’t show any of these “special” relationships. The feature is specific to the Activity Associated View, which is also a “special” thing in the XRM platform, supported by another “special” component called the Social Pane. The implications from this are laid out bare in the feature documentation:

“The primary entity for the relationship must be Account, Contact, or Opportunity. This is because these are the only entity forms in the system where the Activity Associated View appears. You can’t specify any other primary entity for activity rollups.”

So, this is not a generic Holy Grail to presenting activity data in XRM just the way we’d want to, but one big rock rolled in the ditch from that long road at least.

Control how activities are sorted by date

Another new feature in v8.2 that touches upon the same functional area is related to the Social Pane configuration options. Traditionally, these words would not have existed anywhere near each other – aside from the countless feature requests on MS Connect CRM Ideas forum. Everybody liked the CRM 2013 feature in terms of rich presentation and inline editing capabilities, and simultaneously loathed it for being a completely uncustomizable component placed smack in the middle of most XRM entity forms.

It’s not just the business process specific requirements like the ability to add custom fields into the activity cards shown on the Social Pane that have caused pain in many projects (“sure, we could add an optionset field to categorize the phone calls, but most users will never see it”). One particular behavior has been downright destructive when it comes to activity history preservation for your customer data: the activity sort order. You see, up until now the Social Pane has insisted on showing the records in a descending order based on the Modified On date. This works in most scenarios, but where it fails miserably is when some specific event causes the old activities to be updated – be it the reassignment of records to a new CRM user, a data migration from CRM on-prem to CRM Online Dynamics 365, or any similar mass update that touches the modification timestamp (which you can’t directly manipulate even via the API).

Now in the December 2016 update for Dynamics 365 (online and on-premises) there is a new sortdate attribute on the activitypointer entity that you can use to control how activities are sorted by date. That previous sentence has been copy-pasted from the developer documentation of the new version, but in case you don’t spend too much time with the SDK, you’ll be glad to know that the configuration options in the entity form customization UI have been extended, too. In the Social Pane control (or Activities Tab, to use the term shown in the modal dialog instead of the label of the form component), there’s a new Activity Wall tab with an option for “sort the activity wall according to”. No longer are you forced to use the Last Updated default option, but rather can select from a whole host of activitypointer date fields like Date Created or Actual End.

Is this now the Holy Grail for activity management? Well, it would be a comforting conclusion to make, but if you know me, I tend to spot the rain clouds behind every ray of sunlight. In this case, just having a single sort date to be applied by the system customizer for showing all the activities may not satisfy all the users. In fact, this is also implied by Microsoft in the developer documentation describing the enhancements in v8.2:

“Whenever you display a list of activity entities and order them by date, you can only use the common date attributes defined in the activitypointer entity. However, sometimes you want different sorting behaviors depending on the type of activity. For example, with the email entity you might want to sort by the senton attribute value rather than the modifiedon attribute value.

Use the sortdate attribute to control how activities are sorted by date. By default, the sortdate attribute value is null. You must include business logic to populate the date value that will be set for this attribute and then use the sortdate attribute within the query defined for the view. You can set the sortdate attribute value using a workflow or a plugin. For consistent results you should set this value for every type of activity and any existing activity data in the system.”

If I read this correctly, it means that there is now a place in the data model to put the “right” sort date value for each entity. However, to update the value you’ll need to customize the system to populate it. In a data migration scenario you’d probably insert the right value there during the activity record create event. During the normal use of the system, you’d need to have a workflow process (or a plugin for lower performance overhead) running on every single event that can affect the position in which the activity should be listed in relation to the rest of the activities in the views. Yes, this new Sort Date field is now visible for activities even in workflow process editor, so achieving the perfect sort order for your activity history is in theory possible.