Reported by Katherine West - this is an oversight on my part specifically related to the rollup operations that are always full recalculations - like FIRST/LAST/AVERAGE. As part of #80, I made a change that allowed, for updates, calculation items to make it through to the async rollup part even if they were excluded as part of the Calc Item Where Clause.

What really needs to happen is for them to allow a rollup to be kicked off, but to still be excluded during the rollup calculation itself.

• Include the org default CMDT for RollupLimit__mdt (so it's available out of the box)
• Delete RollupLimit__mdt.Rollup__c and instead have Rollup__mdt.RollupLimit__c (required lookup field)

Attempting to deploy from https://githubsfdeploy.herokuapp.com/app/githubdeploy/jamessimone/apex-rollup results in the following errors:

Status: Completed
Deployment Complete

Test failure, method: RollupTests.shouldMaxDateOnInsert -- System.AssertException: Assertion Failed: Records should have been populated MAX DATE AFTER_INSERT: Expected: 1, Actual: 0 stack Class.RollupTests.shouldMaxDateOnInsert: line 1206, column 1

Test failure, method: RollupTests.shouldMinDateOnUpdate -- System.AssertException: Assertion Failed: Expected: 2020-12-06 00:00:00, Actual: 2021-01-30 00:00:00 stack Class.RollupTests.shouldMinDateOnUpdate: line 1278, column 1

These, and OpportunityCompetitor.CompetitorName (which I know nothing about) are the three objects / fields that use this DisplayType. We should support rollups for this - it's likely that this already works for almost all use-cases, but the DefaultSObjectFieldInitializer needs to include that DisplayType enum in the switch statement for string-like objects.

I just set up a rollup from a parent trigger, and it's not running. Any idea why not?

I checked Is Rollup Started From Parent
and added Rollup.runFromTrigger(); to my class which runs when parents are inserted, as the line right after inserting the children.

Do I also need to tell it which child object to roll up? I'm reading through the readme but don't see anything about that when using the CMDT approach (only when using the invocable)

Thanks!

Currently, the field is a text field, so users have to know which values are supported - there is help text that mentions some of the values, but it's not the full list, and users could still mistype the value.

Converting the field to a picklist should make it easier for admins to add new rules, and avoid any issues with invalid rollup types.

This didn’t make the cut for the initial release, but I’d like to get continuous integration up and running in the coming days so all tests are run for new PRs / commits to master

In the event that new rollups are added to an object, or existing rollup criteria is updated, existing data in orgs will need to be fully recalculated to ensure that the data is accurate. There should be an easy way for admins (and developers) to be able to select a object from the org's schema & run a batch job to recalculate all rollups for the selected object.

• User can select 1 object from the org's schema
• User can optionally provide criteria to filter the records that are included in the recalculation
• User clicks a button & a batch Apex job is initiated - the job should recalculated all relevant rollups for the select object

Reference: https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_dateformats.htm

Back in 2017, @jongpie and I added SOQL date literal support to what was then the larger Nebula framework. Though the heyday for Nebula as a full framework has abated, working on the SOQL date literals has stuck with me, and I think it's something that should be supported in Rollup as well.

This change should be constrained to RollupEvaluator.cls and its test class, making it a good first issue to work on.

The only special considerations are for the following date literals:

• THIS_FISCAL_QUARTER
• LAST_FISCAL_QUARTER
• NEXT_FISCAL_QUARTER
• NEXT_N_FISCAL_​QUARTERS
• LAST_N_FISCAL_​QUARTERS
• THIS_FISCAL_YEAR
• LAST_FISCAL_YEAR
• NEXT_FISCAL_YEAR
• NEXT_N_FISCAL_​YEARS
• LAST_N_FISCAL_​YEARS

Because a query will need to be consumed to get any org's fiscal year bounds, these date literals represent a special case. Because we are trying to specifically constrain query consumption within Rollup, if somebody else picks up this issue, I would ask specifically that the query only be made if one of these date literals is passed as part of a Calc Item Where Clause.

Reported by Katherine West -

• FIRST/LAST does not constrain the SOQL query by lookup item - easy fix
• FIRST/LAST may not be correctly getting the SOQL where clause - still need to check on this one
• delete operations on FIRST/LAST need to exclude current items
• return human-readable error message if order by is not passed for first/last from flow
• still run FIRST/LAST if current iteration's items get filtered out via the calc item where clause (since, like AVERAGE, FIRST and LAST are full recalcs every time)

It would be awesome to provide an unlocked package for installing into orgs rather than relying on Andy's GitHub deploy tool. This would make it easier to uninstall and upgrade.

@solo-1234 reported an issue today that was the result of an unintended regression in changes to rollup's filter function. These changes were tested for record-triggered flows but, notably, not for trigger-based flows (where the records which are passed in are in a read-only collection).

Since we have the extra-tests directory to put such things in, add integration tests for both approaches. At present, there is only one trigger-based integration test in extra-tests - and it's a negative test that bails in the lines immediately preceding the ones that solo had an issue with - we can tighten this up!

The rollup app currently exposes the LWC, rollupForceRecalculationin a tab so that full recalcs can be performed. As part of #59, this app's roles have expanded to also allowing the user to select a given calc item based and have all of the CMDT associated with that have their rollups be initialized.

@jongpie had some great feedback to enhance this component further by displaying a table of the existing CMDT records (and potentially allowing the user to opt into which CMDT rollups were included in the full recalc). I am kicking this over to a new issue because I view it as a nice to have (for now), but I think it would really round up the functionality of this feature nicely.

I am intrigued by this project, and am currently using the DLRS tool. I currently use a semicolon to concatenate values in fields that are ingested by other methods. I'm wondering if this feature is on the roadmap. Thanks.

As part of #81, validation rules are now enforced for Rollup operations being passed through Flow. It would be nice to have the singular recalculation rollups kicked off by the Recalculate Rollups app also enforce validation rules, as these are the only two codepaths (invocable / singular recalc) that don't use the Rollup__mdt CMDT (where the validation rules are enforced already).

Hey James,

Been looking forward to implementing this since you released it in Dec; thanks for the solid work.

I got hung up on your screenshot comment:. Recorded a quick video explaining what was going on. Am I missing something? https://share.vidyard.com/watch/RQEwPYY9BmsTrFvtNKrATP

At present, on updates Rollup does not examine the calculation items' lookup field for changes. If reparenting has occurred, a full recalculation must be done for both the existing and old parent records. Related to #6 insomuch as reparenting for CDC updates will be an even bigger knot to untangle.

Don't require all caps to get the job done.

Hi! I'm getting an error with a rollup. When inserting records of the child object, I get:

We can't save this record because the “Rollup Flow” process failed. Give your Salesforce admin these details. Unable to convert value '{...}' to Apex type SObject for Apex action RollupFlowBulkProcessor Variable recordsToRollup Error ID: 1509407456-129770 (-2081482679)

Where the ... represents every field and value on the child record.

This is a rollup that previously worked fine. I tried switching to a flow calling CMDT rollup but I still get the same error.

Any idea what could be causing that? TY

It looks like the grandparent rollup test is failing due to ordering of the values that are getting concatenated. I took a quick glance at the code and didn't see a quick way to fix it. I'm wondering if you should use lists and sets for the concatenate operation. That seems to be a bigger rework, though.

System.AssertException: Assertion Failed: Grandparent rollup should have worked!: Expected: One, Two, Actual: Two, One
Stack Trace: Class.RollupTests.shouldAllowGrandparentRollupsFromParent: line 3039, column 1

It'd be really useful to add the ability to grab the first/last values in related records & roll it up to the parent records. These serve a slightly different purpose than 'min' and 'max'. The first/last values are more focused on when the value was entered into the system (based on sorting of the child records) - the values may not necessarily be the same as min/max values.

Expected behavior

• Both operations should support all primitive data types (string, decimal, date, datetime, etc.)
• 'First' should return the value from the oldest child record (based on sorting on a specified 'order by' field in the Rollup__mdt CMDT
• 'Last' would do the inverse - return the value from the newest child record

Currently, Rollup does not support some operators that are specific to multi-select picklists: includes and excludes (source). These behave a bit differently from equals and not equals since multi-selects are stored as semicolon-separated values.

Multi-selects definitely aren't Salesforce's best idea, but since they're not going away any time soon, it'd be nice if Rollup supported the operations.

Additional steps necessary:

• package versions should be created automatically
• commits to main branch should promote package version automatically
• README links to currently promoted package should be replaced on commits to main
• Github Action should re-commit the file updates (sfdx-project.json and, on commits to main, README.md) within the pipeline

If you are in a batch Apex job that causes a rollup to fire, you might get an error First error: Too many queueable jobs added to the queue: 2. When determining whether or not to enqueue the job, check to see if you have room to enqueue another job. Check Limits.getQueueableJobs and Limits.getLimitQueueableJobs(). If there are no more queueable jobs, then either run the rollup in batch (but maybe check limits there too) or synchronously.

Right now, Rollup defaults to comma-separated for concat operations, but users should have the option to use the delimiter of their choice (via @solo-1234)

While working out the kinks in #45, I fixed a bug with CONCAT_DISTINCT - which got me to thinking about concat operations in general, since the text field I was working with was only 255 characters long. Rollup should use Database.DMLOptions and the allowFieldTruncation property to avoid running into an error when updating parent records.

At present, concat distinct on delete operations simply removes the deleted entries from the rolled up item - but that's a bit naive, as other children items out of the scope of the rollup may still contain the distinct value. We'll need to re-query to keep things in good working order.

Thanks to Katherine West for reporting this one!

Currently, the custom metadata type does not provide a way to add filters for the records - but a common use case is to only include a subset of records in a rollup. For example, you may want a rollup on Account of the total number of related Contacts with status = "some value". Currently, all related records will be included in every rollup.

Hello!

First off, thank you so much for all your work in putting this together, and simplifying many dev lives!

It looks like RollupFieldInitializerTests on line 33:
System.assertEquals('', initializer.getDefaultValue(Task.Subject), 'combobox');
Is expecting an empty string, but if there is a default set on the org, the assertion fails as the default is what is returned.
Removing a default value allowed deployment.

Unrelated Question: Last time i tried using CMDT, but the object list did not show Task nor Activities. Are those not supported with CMDT?

Thank you again!

In some situations, like data migration, it'd be useful to be able to temporarily disable rollups from executing - a new custom hierarchy setting with a checkbox fields seems like the cleanest approach & would let you disable it just for certain users, profiles and/or the entire org.

The "Recalculate Rollup" component currently requires you to enter all of the rollup details. This works great with having full control - but if you've already defined a Rollup__mdt record with all of the details, it's a little repetitive to have to re-enter it. Ideally, this component should have 2 options to select from

1. Manual Entry - the existing functionality. This is definitely nice to have, and it's required in order to do rollups for objects like task, event & user since they're not currently supported in CMDT EntityDefinition fields
2. Select Existing Rollup - new functionality. When this option is used, the component should show a list of Rollup__mdt records (maybe displayed in a dropdown?) for the admin/user to select

In either scenario, I think you'd still want to be able to specify a WHERE clause, so the existing input "Where Clause SOQL Filters (Optional)" should be displayed for both options.

Hi! I'm thinking it would be useful to have the ability to call rollups (either via trigger or flow) from the parent object. One example would be for scheduled flows running on the parent (which is cleaner than running on the child).

Thanks!

This feature request from @elements:

Currently, rollup assumes that the only 1 : many relationship is from the parent to each "child" object in the hierarchy - but it would be great to allow something like rolling up fields from Opp Line Items straight to Account, for example; cutting out the Opportunity middleman.

For multiple "jumps" between objects, the relationship between the "lookup field" (since it can be a string or Id) to the parent object would have to be established (possibly using "Apex map" syntax a la @tsalb's Custom Column Labels in lwc-utils, or with another CMDT that's related to Rollup__mdt). Being able to use filtering criteria on the in-between objects should also be supported.

From an admin's perspective, it's a little confusing have 2 separate checkbox fields when only 1 can actually be checked at a time - the new field could be called RollupLimit__mdt.ShouldRunAs__c (or something along those lines)

From Salesforce's documentation:

The maximum number of scheduled flow interviews per 24 hours is 250,000, or the number of user licenses in your org multiplied by 200, whichever is greater. One interview is created for each record retrieved by the scheduled flow's query.

Need to do one or both of:

• Refine Readme to showcase the potential downsides of using scheduled flows as the scheduling agent for Rollup - the intent was for the Get Records action to be used to bulkify things, but not if each record retrieved is run as a singular flow interview
• Enhance the existing invocable to take in a query / field parameters to find the calculation items in question, or some other criteria-based solution that correctly allows for bulkification for invocables started via a schedule

Feedback via @LawrenceLoz

Giving people more options for invoking Rollup: https://trailhead.salesforce.com/en/content/learn/modules/change-data-capture/subscribe-to-change-events-using-an-apex-trigger

It would be useful to be able to call CMDT rollups from flow. I would either want to pass in an id/name of a CMDT record (or maybe even a list), or supply the object/record and run all rollups configured for it (just like the apex trigger method works).

Thanks!

Now that #25 has been released, it's not always the case that after insert, after update, before delete, after undelete are all required when the rollup is initiated from the parent. Update the README accordingly with more information on when these contexts are required (vis a vis @solo-1234)

I set up a CMDT Rollup where the Order By (First/Last) field name was different from the Rollup Field On Calc Item. When I treid to trigger the rollup by creating a new record of the relevant calc object, I receive an AfterInsert/AfterUpdate error System.SObjectException: SObject row was retrieved via SOQL without querying the requested field.

I was able to reproduce this error with different objects. Every time OrderByFirstLast__c on the CMDT Rollup record was not the same as RollupFieldOnCalcItem__c, I could not save new records of the object specified as the calc item.

(apologies if this is not the correct format for logging issues like this, it's my first time opening an issue on a project!)

I'm trying out the full rollup using CMDT with different where clauses. The batch is failing because of the dreaded error SObject row was retrieved via SOQL without querying the requested field. I'm not sure if it matters, but the field I'm filtering on is a formula field.

I have 4 CMDT records for one calc item. Each one has a different where clause.

Here's my stack trace:

FATAL_ERROR System.SObjectException: SObject row was retrieved via SOQL without querying the requested field: [fieldname]
FATAL_ERROR Class.RollupEvaluator.WhereFieldCondition.getFieldValue: line 481, column 1
FATAL_ERROR Class.RollupEvaluator.WhereFieldCondition.equals: line 415, column 1
FATAL_ERROR Class.RollupEvaluator.AndConditionalGrouping.conditionallyEquals: line 374, column 1
FATAL_ERROR Class.RollupEvaluator.ConditionalGrouping.equals: line 336, column 1
FATAL_ERROR Class.RollupEvaluator.WhereFieldEvaluator.matches: line 134, column 1
FATAL_ERROR Class.Rollup.filter: line 2140, column 1
FATAL_ERROR Class.Rollup.: line 221, column 1
FATAL_ERROR Class.Rollup.RollupAsyncProcessor.: line 318, column 1
FATAL_ERROR Class.Rollup.loadRollups: line 1962, column 1
FATAL_ERROR Class.Rollup.getRollup: line 1844, column 1
FATAL_ERROR Class.Rollup.getDelegatedRollup: line 2037, column 1
FATAL_ERROR Class.RollupFullBatchRecalculator.execute: line 35, column 1

When attempting to deploy to Salesforce we encountered the following errors:

Invalid type: ContactPointAddress
Invalid type: ContactPointEmail

This appears to be due to the fact that we do not have 'Person Accounts' enabled in our org and this field comes from there.

There are a number of related errors all coming from the 'RollupTests' class for fields related to these two types.

Hello Again, Thank you for the quick fix on the previous issue!

I was using the apex .batch method and realized I also wanted to use FullRecalculationDefaultNumberValue__c = 0 with it, but it defaults to using whatever is in the target field. I know I can use a flow instead for this, but I am wondering how to go about rolling up multiple fields to an object without running into a limit? If I chain a bunch of Actions in the flow for each rollup, I assume each runs on its own, using SQL + DML in each? If that's the case, it might be good to allow decoupling the final DML in the flow as an option, collecting the records after each Action, and doing the final Update all at once via a Flow Update node.

Also, would I need to create an Action node per rollup context (INSERT / UPSERT / UPDATE / DELETE) or one for UPSERT & Another for DELETE, to cover all scenarios of the rollup?

It would be neat if we could call rollups from anywhere in apex - even without a trigger, pass in a record collection and trigger context, and let it run all the CMDT rollups for that record collection. That would make this much more flexible in terms of where it's running and on which records.

It's possible to use the flow invocable action from apex, but it involves quite a bit of code:

        rollupInput.recordsToRollup = myRecordCollection;
        rollupInput.rollupContext = 'INSERT';
        rollupInput.deferProcessing = false;
        List <RollupFlowBulkProcessor.FlowInput> rollupInputs = new List <RollupFlowBulkProcessor.FlowInput> {rollupInput};
        List <Rollup.FlowOutput> rollupOutputs = RollupFlowBulkProcessor.addRollup(rollupInputs);
        System.debug('rollupOutputs: ' + rollupOutputs);

It would be awesome if we could get a more concise way, something to the tune of this:
Rollup.runFromApex(List <sObject> records, String rollupContext, Boolean deferProcessing)

Thanks!

By default, Salesforce archives old Task and Event records, so a query like [SELECT Id FROM Task]; would not necessarily return all tasks in the org. Instead, you'd have to use a query like [SELECT Id FROM Task WHERE IsDeleted = false ALL ROWS];. This scenario needs to be taken into consideration so that rollups are accurate when using Task or Event.

Since several people/orgs are switching from DLRS to Rollup, it'd be great to have a way to automatically convert existing DLRS rules to Rollup rules. Not all orgs will need this extra code, so this should probably be kept outside of the main rollup directory.

As far as implementation goes, it will probably be a new batch job that re-uses some logic in my CustomMetadataSaver repo to deploy the CMDT records. This will allow admins to convert DLRS rules directly within an org (instead of having to use SFDX or other external tools)

When a rollup fails, it would be nice to log this error and the parent record that wasn't successfully updated. This could let an admin review the errors and try to fix whatever might be the problem. When things are running asynchronously, these errors just kind of disappear. For example, I see some errors in my Apex Jobs view, but I don't know which record failed or even what caused the problem. I just see Attempt to de-reference a null object.

I'm trying to troubleshoot why my rollup isn't rolling up the right number in my trigger. I'm trying to force recalculation by requesting the rollup from the Recalculate Rollup tab. When I do, I get this error:

Here's the values I entered, just in case I'm doing something wrong.

Currently, Rollup will just produce one string of comma-delineated values as multiselect picklist value.

Repro steps:

1. Create a record triggered flow (after create) for child object
2. Add a Get Element for Parent object
3. Add a Get Element for the correct children of the Parent
4. Rollup Invocable with the following variables:

• Calcitemrollupfield of a String
• Lookup Field on Calc Item is a Lookup to Parent
• Lookup field on Rollup Object is Id of Parent
• Rollup Context is update
• Rollup object field is a multiselect picklist field
• Rollup op is CONCAT_DISTINCT
• Rollup target's SObject name is Opportunity
• Records to rollup is variable from Step 3

Envrionment Variables:
Spring 21/api 51

Currently some users experience issues installing / upgrading Rollup due to heavy test code usage of the Opportunity object, which is also commonly used in many other platform automations. Consider migrating tests to a lesser-used standard object to avoid this pain point. This issue also prevents some users from installing other packages on the fly, unless they disable their automations each time.

Alternatively: add option to Org Default Rollup Control to skip test asserts.

cc @RomanTheCube

This situation brought to me by Julie Smack:

• Rollup items are fetched using an auto-launched flow's Get Records collection - different Rollup actions are stipulated in this flow, or sub-flows
• Those Rollup actions use the Calc Item Where Clause to filter items based on criteria
• At present, some rollup calculations don't have any results for a given flow interview, so Rollup aborts early - even though the full dataset is present

For situations like this, add support for indicated to Rollup that the list of calc items present for a given rollup is the full dataset. This, in conjunction with the pre-existing Full Recalculation Default String Value and Full Recalculation Default Number Value can be used to reset the lookup item's rollup field when there are no calc items for it in the given rollup.