With the release of Roll-up fields in Dynamics 2015 we can now compare the two platforms with respect to code-free aggregation. What is a roll-up? Simply put, it is a field that calculates values from related records. Examples include the total expected revenue from open opportunities on an account and the number of outstanding cases for a customer service agent.

Aggregate Functions

The following functions are potentially available depending on the field type. Some fields understandably are not applicable for use in aggregate calculations. Please consult the related documentation in Dynamics and Salesforce for specifics not covered in this post.

  • COUNT
  • SUM
  • MIN
  • MAX

Create a Roll-up Field

The use case for this example is “Display the total expected revenue from all open opportunities with a probability of greater than or equal to 70%.” Before we begin it is critical to understand the relationships that are required. Obviously, the field containing the aggregated value lives on the “master” or parent record. In this case we are using Account for the parent. The account has a number of associated opportunities, and each of these records is tied back to the parent account.

Dynamics has a single 1:N relationship that satisfies this requirement: a lookup relationship. Salesforce complicates the matter by having both a lookup and a master-detail relationship. Only the latter can be used for this purpose. Consult the Salesforce Developer’s Guide or this post for more information.

This is one occasion where the two platforms are almost identical. The primary distinction is the lack of a specific roll-up data type in Dynamics. It makes sense that the result of an aggregate function can only be of a few select types, namely numeric (SUM, COUNT, MIN, MAX) and date/time (MIN, MAX). Therefore, selecting the data type will filter the field type. Possible field types include Simple, Calculated and Rollup. In the case of Salesforce select the Roll-Up Summary data type. From this point forward, except for a different order for assigning filters and aggregations, you are a few keystrokes away from completion with either platform.

Out of the Box Relationships

In this example the Source Entity (Dynamics) and Master Object (Salesforce) are predefined based upon the object on which the field is placed. Where it becomes interesting is the out-of-the-box relationships. Recall that Salesforce roll-up summary fields must be based upon master-detail relationships. This example uses a new organization and for accounts there is only one predefined master-detail relationship: opportunities. Contrast this with Dynamics where every standard lookup relationship is available, including activities, quotes, opportunities, orders, letters, leads and more.

Refresh Frequency

Perhaps the greatest distinction between the functionality of the two platforms is the refresh frequency. There is a lag time (12 hours for Dynamics and 30 minutes for Salesforce) between creating the field and updating all records impacted by the addition of the field. From that point Dynamics runs a recurring system job that updates the roll-ups hourly. This means that the field value may be incorrect for up to an hour. In many circumstances this may not be significant. Regardless, it clearly is a topic that should be covered in training.

If this lack of immediate synchronization becomes an issue, the user can hover over the calculator icon (see the previous figure) and note the last time the roll-up field was updated. If it is out of sync a manual refresh can be executed by clicking the refresh icon. As indicated by the arrow the user should see an immediate update.

In contrast, Salesforce refreshes the roll-up summary field each time it is displayed.

Due to the extensible nature of Dynamics there already is an open source CodePlex project available that provides on-demand updates via a custom workflow activity.

Other Differences and Limitations

There are many nuances in both platforms that are beyond the scope of this post. One notable difference is the ability (or inability) to use a roll-up to trigger workflow rules. Salesforce supports this, Dynamics does not. Suppose an escalation email must be sent if an account exceeds a set number of unresolved cases. A Salesforce administrator can accomplish this with a simple workflow rule whereas code is required in the Dynamics implementation.

Security is an issue with both platforms. A user may only have access to some and not all of the records that are used to calculate the roll-up value. Since the calculations are performed under the security of a system account this user may see figures she should not have access to. For example, a user might be able to “reverse engineer” the result based on other fields in order to ascertain information he is not entitled to know. Therefore, consider using field level security to hide the roll-up field where applicable.

Creating roll-up fields is simple in both platforms but their execution, impact and relations to other fields and calculations are quite complex. Please take the time to read the Salesforce documentation referenced in earlier links. As far as Dynamics is concerned, Jukka Niiranen has an excellent post on the “gotchas” found with roll-ups.