v1.2.0 - Grandparent Rollups (Original)
Grandparent (Or Greater) Rollups
It's not all that uncommon, especially with custom objects, to get into the practice of rolling up values from one object merely so that another parent object can receive those rolled up values; that is to say, we occasionally use intermediate objects in order to roll values up from a grandchild record to a grandparent (and there's no need to stop there; it's totally possible to want to roll up values from great-grandchildren to the great-grandparent record, and so on). Rollup
offers the never-before-seen functionality of skipping the intermediate records so that you can go directly to the ultimate parent object. This is supported through the invocable rollup actions, as well as through the CMDT-based rollup approach by filling out the optional field Grandparent Relationship Field Path
:
In this example, there are four objects in scope:
ApplicationLog__c
, which has a lookup fieldApplication__c
Application__c
, which has a lookup fieldParentApplication__c
ParentApplication__c
, which has a lookup fieldAccount__c
Account
, and the field we'd like to rollup to has the API nameAnnualRevenue
Important things to note about grand(or greater)parent rollups:
- super important all intermediate objects in the chain (so, in this example,
Application__c
, andParentApplication__c
) must also have theRollup.runFromTrigger()
snippet in those object's triggers (or the appropriate invocable built). This special caveat handles cases where the intermediate objects' lookup fields are updated; no big deal if the ultimate parent lookup hasn't changed, but big deal if the ultimate parent lookup has changed - if your CMDT/invocable is set up with a relationship that is not the immediate parent and you don't fill out the
Grandparent Relationship Field Path
, it simply won't work. The field path is required because it's common for objects to have more than one lookup field to the same object - if you are using
Grandparent Relationship Field Path
with a polymorphic standard field likeTask.WhatId
orTask.WhoId
, you should also supply aSOQL Where Clause
to ensure you are filtering the calculation items to only be related to one type of parent at a time. Note - at this time, theSOQL Where Clause
only works on the fields present on the initial calculation items, and does not support cross-object filtering - grandparent rollups respect SOQL's map relationship-field hopping of 5 levels:
In each specified relationship, no more than five levels can be specified in a child-to-parent relationship. For example, Contact.Account.Owner.FirstName (three levels)
While the base architecture for retrieving grand(or greater)parent items has no technical limit on the number of relationship field hops that can be made, correctly re-triggering the rollup calculations after an intermediate object has been updated made it necessary to respect this limit (for now).