Is this actually performing a Recalc?

[ghost]

Hey James,

Love all your work, thank you for your contributions.

Just a quick question - I've just installed v1.5.71 and jumped straight in. I set up the Org Custom Setting, and then created 2 CMDT based flows (UPSERT + DELETE) to see how it works.

I didn't do a Full Recalc to start with - i just added a child record with values to see them rollup.
It calculated the value on the record i added - and populated this value onto the parent record....BUT...it didn't grab the values from the existing children records and include them / roll-them-up....so my question is:

Is this designed to do an actual rollup calculation - I'll call this FullCALC (get all children records and calculate the value to rollup), or is it just rolling-up a calculation of the changes - i'll call this DeltaCALC (i.e. this change is an UPDATE...old vs new = 50 vs 100 = +50....therefore parent field += 50?)?

After this observation, i went and read more of your wiki and performed a Recalculate Rollup using my CMDT records and it correctly rolls-up all the children records into the Parent field.....so my immediate thought was maybe i should just use this every time?

Is there a setting that chooses the FullCALC option everytime?
If not, was the intent to set a baseline when first set up, and then use the DeltaCALC and hope that things never got out of sync, and use the Recalculate Rollup to get things back on track if they did / scheduled basis to make sure?

Apologies if i am using things incorrectly...I'm going to read all the wiki pages now....

[ghost]

Ok - so to get a FullCALC every time, it looks like i can either:

1. use a GET RECORDS element and pass in all children, then use IS FULL RECORD SET and 'Full Recalculation Default Number Value = 0' or
2. use REFRESH as the Rollup Operation Context

does that sound right?

P.S. it doesn't look like REFRESH works correctly with a Record Trigger Delete flow....i manually set the parent rollup field to an incorrect higher value, then deleted my only child record and the parent rollup field didn't update at all.....i then used the Recalculate Rollup tab/page and it recalculate the field correctly...
Setting the flow rollup operation context back to DELETE only does the DeltaCALC - i.e. when deleted, it subtracts that amount from the parent rollup field - but it doesn't recalc, so if that parent field was wrong, it is still wrong but now minus the deleted value

[jamessimone]

I will try again to reproduce the record-triggered flow delete case, I'll keep you updated on that front

[jamessimone]

@jmsctm you're correct that REFRESH won't work for a Record Trigger Delete flow - however, that's by design as the framework otherwise has no way to know that the records being passed to the delete flow are, in fact, being deleted. The correct context to use here is DELETE.

[jamessimone]

Hey! Thanks for reaching out. Let's walk through what's going on and hopefully I'll answer all your questions:

• for COUNT, SUM, and CONCAT-based rollups, yes, the original intent was to only perform delta calculations because that's all that's needed to do the calculations
• the idea was that after one full recalc had been performed, delta calculations would suffice from there on out. While some people do perform scheduled full recalcs to do things like calculate rollups that rely on relative date-based logic (eg all opportunities in a certain stage for this month), outside of those special cases the idea is that once you've set up all of your rollups and used the full recalc app to stamp your records with the current state of things, it shouldn't be necessary to use the full recalc app at all unless you're adding new rollups
• as I added more and more operations, many of them were much more complicated and relied on the rollup engine knowing about all children for a given parent; delta operations for every other operation type (including offshoots of some of the original delta-based operations, like COUNT_DISTINCT and CONCAT_DISTINCT) weren't feasible
• at some point, I changed the behavior behind the "Is Full Record Set" flag for any given rollup operation; you can now use this flag on a COUNT/SUM rollup to transform it into a full recalc-based rollup every time (in essence, shifting it from a delta-based operation to one that queries for the other children)

I hope that helps!

[ghost]

Hey James!

Thanks very much for both getting back so quickly and the detailed response.

I look forward to trying all of the flavours of the various rollup types, and will figure out if/when we need a full recalc. Would love to set-and-forget...but feels like i'm tempting fate 🤔