Is there a way to configure APEX Rollup to ignore records during a full recalculation?

[cdevelin]

Hi James,

If am rolling up transactions in a Transaction Object, to a Summary object which summarises the transactions by period (in this case, each period is a Year), but I want to reduce the amount of transactions picked up during a full recalculation, is there any way to do that?

E.g. Simple scenario, a full recalculation of the transactions relating to each year to the appropriate 'Period Summary' record works fine:

However, if I want to reduce the volume of transactions considered during a full recalculation, my thought was to add a 'WHERE' clause to specify to only roll-up periods where status = 'Open',

i.e. my rollup WHERE clause is

Period__r.Status__c = 'Open'

and then the full recalculation would skip over all the grayed out transactions because they belong to closed periods and just recheck the transactions in green add up to the green balance.

However, that is not what is happening. I cannot stop it rechecking the balances of all the years, even if they don't really need to be rechecked, but because of my WHERE clause, there are no valid transactions found, and this is results in the highly undesirable result of the closed periods which previously had a correct summary balance being incorrectly recalculated to zero.

I don't want to roll-up from 'Parent to Child', I still want the normal Child to Parent rollup, so that each transaction as it is created adds itself to the periodic summary in near real time.

However, I'm concerned that as the Transaction object gets huge, the unnecessary workload on a recalculation to recheck periodic totals which are never changing is a waste of time and may ultimately fail and become impossible to run in a large org.

Maybe I'm asking for a 'WHERE' clause on the Parent? i.e. only update Parent records who meet the criteria of the Parent 'WHERE' clause, with children which meet the criteria for the children 'WHERE' clause? That way I could specify 'Period__r.Status = 'Open' on the parent and reduce the workload on a full recalculation.

Any existing solution to this issue of course gratefully received!

[jamessimone]

The where clause should be used to cut down on the number of records used in a full recalc. You can disable the parent fields being reset for records that don't match, as well - that's a configuration option on the Rollup control record (Should Skip Resetting Parent Fields, IIRC).

Full recalculations that mix and match where clauses (so, ones that are performed on multiple Rollup records at once) will retrieve a wider swathe of records that are then filtered down in each given calculation, but otherwise using a parent-level where clause should already be leading to the results you're looking for (with the exception, it sounds like, of the non-matches getting unintentionally reset, but hopefully that config option I mentioned covers that for you).

Let me know what you think! I will of course support any other changes that need to be made.

[cdevelin]

Hi James,

I tried the 'Should Skip Resetting Parent Fields' and it worked as desired when doing a full recalculation in one scenario, but not in another.

When doing a full recalculation only on the transaction rollups which rollup to the Summary object, then if I closed the period, the closed summary period records were effectively skipped, and not recalculated incorrectly to zero, so this works well.

However, the transaction record also has an 'amount due' field which rolls up to a different object (and amounts due from a closed period are still due!).

If I do a full recalc and select all the rollups to the summary object and don't remember to deselect the recalc of rollup to the 'total due' field on a different object, because the 'closed period' transaction (rolling up a different field) is still being included in the roll up to the total due, it ignores the skip resetting parent option and recalculates the closed summary period to zero again.

i.e. this works as desired and skips summary periods which are closed:

running this full recalc with the rollup to a different parent object being recalculated at the same time causes closed summary periods to be recalculated to zero:

I think it would be much safer if a user did select to do a full recalc on a particular child object which had rollups to different parent objects, that if the 'skip reset' option was active, it grouped the rollups by parent object and ran each group separately, since running these two full recalcs sequentially:

is a completely different result to running this full recalc as a single job (which results in the extremely undesirable outcome of closed periods being zeroed):

[jamessimone]

@cdevelin do your metadata records happen to have a Full Recalculation Default Number value set up, by chance? As far as I can tell, that's the only way that parent values would get reset at the moment (assuming you have the Should Skip Resetting Parent Fields toggled on your Rollup Control(s)).

Let me know!

[cdevelin]

Yes, I put “0” as my full recalc default value rather than null pretty much as a rule. Are you saying that the behaviour is different, i.e. a full recalc with a default of zero will set a record to zero when there are no eligible children in the rollup, but a default of null doesn’t set a null to override the current field value, it genuinely just ignores the parent?

[cdevelin]

My understanding is that it is generally considered best practice to set a custom numeric fields default to zero, and Chat GPT agrees and provides these guidlines

Best Practice (Set Default to 0)

Set default to 0 when:
• The field will always participate in calculations, even before it’s explicitly filled in (e.g., running totals, rollups, reporting).
• The field represents a count, balance, or quantity (e.g., “Number of Visits”, “Amount Paid”).
• You want to avoid null handling in Apex, formulas, or flows.
• Example: Total__c + CustomAmount__c won’t fail or return null if CustomAmount__c defaults to 0.
• The field appears in reports or dashboards, and you want to avoid empty/null visuals.

⸻

Not Recommended (Don’t Set Default to 0)

Avoid defaulting to 0 when:
• Zero is a meaningful value, distinct from “not yet set.”
• Example: Discount__c where 0 means “no discount”, but null means “not determined yet.”
• You want to detect missing data, like user input that hasn’t happened yet.
• You use null checks for conditional logic (e.g., flows that run only if value is not null