Perform Rollup__mdt based rollup Invocable

In addition to the "base" action, you have the option to configure rollups using the Rollup Custom Metadata Type records. Like the base action, this one is most easily called from a Record-Triggered Flow, where you have access to the $Record and $Record_Prior variables.

There are two key differences with this action:

• the optional invocable properties act as overrides for what you have set up on your Rollup Custom Metadata Type records (more on this in the optional property section)
• the Defer Processing property defaults to {!$GlobalConstant.True}, which means that you also need to add the Process deferred rollups action after this one so that rollups will run

Prerequisites

Please ensure you've enabled the Rollup Setting Custom Setting org default record prior to setting up any flows - otherwise your rollups won't calculate!

Setting Up Your Record-Triggered Flow

Let's start from the beginning by going screen-by-screen on a new Record-Triggered Flow:

To properly pass your input variables to the flow, create two Collection variables (you can call them whatever you'd like; I tend to go with Records and OldRecords):

• the easiest way to do this is to start in an Assignment element and click the box under the "Variable" section
• click "New Resource"
  • Resource Type: Variable
  • API Name: again, I usually go with "Records" and "OldRecords"
  • Description: optional
  • Data Type: Record (be sure to check off the "Allow multiple values" checkbox)
  • Object: select the same object that your Record-Triggered flow starts from
  • Availability Outside The Flow: make sure to check off "Available for Input"
• select your newly created resource and change the Operator value to "Add"
• use $Record as the value for your "Records" collection, and $Record_Prior for the "OldRecords" collection. Note that the assingment of $Record_Prior is only necessary if you're using a Record-Triggered Flow set to run when A record is created or updated

Here's what your Assignment element should look like once all that jazz is done:

Once you've assigned your variable(s) to their respective collections, you're ready to interact with the CMDT-driven invocable action! Click the "+" sign on your flow path and under "Interactions", select "Action" - by default, the actions are brought up with "Categories" as the filtered-on drop-down on the left side of the pop-up. If you scroll down within this categorized list, you'll find "Rollups" as one of the listed categories:

Now, when you start typing in the Action search bar on the right side of the pop-up, you'll only see options out of the three invocable actions included with apex-rollup:

The second search result, Perform Rollup__mdt-based rollup is the CMDT-driven invocable action. Once you've selected that, the pop-up will transform and you'll be able to start entering the required information for this Action to work! You'll have to fill out both objects under the "Select Objects" header with the type of child object you're working with (footnote below) before the other invocable fields will be shown:

Footnote: Unless the rollup is triggered from the parent using the Is Rollup Started From Parent optional field, in which case you would be selecting the parent type here.

Once you've filled out these fields, the rest of the Action's fields are displayed:

Filling Out Action Fields

Now, let's walk field-by-field through the pictured options on the base Action so that you know exactly how to fill it out:

Required Fields

Important note before beginning - while the below field is the one required field, there are two record collection fields in the optional section, at least one of which is actually required.

• Rollup Operation Context - for a Record-Triggered Flow, this describes when the flow will run:
  • INSERT - if your flow only runs after a record is created
  • UPDATE - if your flow only runs after a record is updated
  • UPSERT - if your flow runs after a record is created or updated
  • REFRESH - if you want the rollup action to fully recalculate the rollup values for any parent object that has children records passed through the flow
  • DELETE - if your flow runs before a record is deleted

---

Optional Fields

At least one of the two record collection fields here are actually required; they are listed as optional to prevent some Flow -> Apex issues:

• Prior records to rollup -- only required if you are using a RT-flow set to run on create and update, or an update RT-flow. Use the collection variable you've already set up in your assignment element and reference the collection variable you made earlier that contains $Record_Prior
• Records to rollup -- actually required for all flows calling the Apex action. For a Record-Triggered Flow, you'll use the collection variable you made earlier that contains $Record. This collection could also be set to the results of a Get Records element.

---

In addition to the required attributes for your invocable, there are quite a few optional properties that can be filled out. The big difference between these optional properties in comparison to the optional properties for the base invocable action is that these properties act as overrides for what you would set up on your Custom Metadata Type; this means that for the most part, you won't use these optional properties, but if you have some special scheduled flow or Record-Triggered flow where you need very specific filtering rules (for example), you could override the SOQL Where Clause To Exclude Calc Items to only consider very specific records.

Without further ado, the additional properties:

• Child Object Changed Fields -- a comma-separated text variable holding the API names of fields you'd like to check for changes. Note that for Record-Triggered Flows using the UPSERT rollup context, this calculation won't be done for records that are being newly created; the check will only be done for items that are updated. If you are using a SOQL Where Clause To Exclude Calc Items, I would not recommend using this field.
• Child Object Type When Rollup Started From Parent (optional) - only necessary to provide if Is Rollup Started From Parent field is enabled and set to {!$GlobalConstant.True} or if you are using the base Rollup invocable action to detect reparenting for an intermediate parent in a grandparent rollup. Normally in this invocable, the child object type is figured out by examining the passed-in collection - but when the collection is the parent records, we need the SObject API name of the children items to be explicitly defined.
• Concat Delimiter -- by default, operations using CONCAT or CONCAT_DISTINCT will use a comma when appending additional values. You can override this default by supplying a value here. Note that if you are rolling up to a multi-select picklist, this field value will be ignored in favor of a semi-colon.
• Defer Processing -- Defaults to {!$GlobalConstant.True} when not toggled. If you don't want to use the Process Deferred Rollups action, toggle this and set to {!$GlobalConstant.False}.
• Full Recalculation Default Number Value -- entering a number in this field will use that number (instead of whatever pre-existing value is on the parent record) as the basis for beginning rollup calculations.
• Full Recalculation Default String Value -- same as Full Recalculation Default Number Value, but for all text-based rollup fields.
• Grandparent Relationship Field Path -- please see the Grandparent Rollups section of the README for full details.
• Is Full Record Set -- use with caution. By default, rollup operations don't assume that the children records being passed in are the full list of children for any given parent record. However, if you know that the records being passed in will always be the full list of children for a given parent (most typically because you've just retrieved all applicable children via a Get Records element), you can set this field equal to {!$GlobalConstant.True}. You'll also want to use either Full Recalculation Default Number Value (if the parent field is a number) or Full Recalculation Default String Value (if the parent field is text-based) when using this field. Also note that some operations (AVERAGE, CONCAT_DISTINCT, COUNT_DISTINCT, FIRST, LAST) always try to make sure (by using SOQL) that additional children related to the same parent don't exist prior to rolling up, because those operations don't "work" in the absence of the full record set. For those operations, you don't need to use this field, because you're already covered.
• Is Rollup Started From Parent -- set to {!$GlobalConstant.True} if the records that are triggering the rollup are the parent-level items, and you want to recalculate the rollup field(s) for the parent items. If this field is used, you must also fill out Calc Item Type When Rollup Started From Parent.
• Order By (First/Last) (optional) - only valid when FIRST/LAST/MOST is used as the Rollup Operation (alternatively, if a Limit Amount is stipulated). Accepts a comma-separated list associated with the fields you'd like to order by, including the sort order and null sort order. For example: Name nulls last, Industry would use the Name field on a record with nulls last, followed by a sort on the Industry field to do tie-breakers. This field is optional on a first/last operation, and if a field is not supplied, the Rollup Field On Calc Item is used.
  • If this is not filled out, the rollup items will be ordered using the Rollup field on Calc Item field for rollups where ordering is required.
• Should rollup to ultimate hierarchy parent -- must be used in conjunction with Ultimate Parent Field (below). Enables hierarchical rollups on any lookup field that is self-referential (e.g. a lookup field back to the same object as the Lookup Object field). Set to {!$GlobalConstant.True} to enable.
• Should run sync -- basically the opposite of Defer Processing (though the two can be used in tandem -- spicy!). When set to {!$GlobalConstant.True}, rollup calculations will begin immediately. If Defer Processing is also enabled, the synchronous part will only begin after the Process Deferred Rollup action is called.
• SOQL Where Clause To Exclude Calc Items -- think of this like adding a SOQL where clause to rollup calculations. Please see the Special Considerations For Usage Of The Calc Item Where Clause section of the README for advanced tidbits.
• Ultimate Parent Field -- used in conjunction with Should rollup to ultimate hierarchy parent. The API name of the field on the Lookup Object that contains the hierarchy lookup field. On Account, this would be ParentId. Unlike Lookup Field On Lookup Object, where a lookup field isn't truly required so long as there is a matching key value from the Calc Item Lookup Field to the Rollup Object Lookup Field, this field truly requires a lookup field as the backing value.

Finishing Setting Up Your CMDT-driven Rollup

As a reminder, if you are not toggling the Defer Processing optional property on this action and setting it to {!$GlobalConstant.False}, you will also need to add the Process Deferred Rollups action after your CMDT rollup action(s) have been added.