Rollup Setting Value, Then Resetting it 0 Immediately After

[tony-jones-tanium]

Hi James - We have been using your package for a while now and love it! Recently, we have noticed that one of our Rollups (we've noticed because its the only field that we are tracking history), is setting the value when the Apex Rollup runs, and then immediately changing the value to 0. We have a pretty simple Rollup CMT record:

But as you can see, its setting the number to $0 at times, when it shouldn't. Does this have anything to do with the Full Recalc Default Value?

Any insight is greatly appreciated! Tony

[jamessimone]

Hey Tony, thanks for reaching out. I haven't seen something like this before but I can take a look. One thing you can try, in the meantime, is toggling the Is Full Record Set checkbox on your rollup record. That retrieves all other records for the same parent behind the scenes, and in this case might help if there's some bug at play here. I don't think it's the full recalc default value by itself, though; that only really means that the value you're resetting to is 0 instead of null.

When you're seeing these updates to zero, do you by any chance know if it's coming from a child record that doesn't match the where clause? In either case I hope to have enough info to go off of already, but every little bit helps.

[tony-jones-tanium]

Thanks James! I've toggled the Full Record Set checkbox to true, and I will check a few of the Accounts after the scheduled flow runs at noon PST today to see if I see any of the Rollup amounts reverting.

As for the child record(s) that do not match the where clause, there are 20 total Opportunities on the Account, with only 1 that meets the were clause. But that Opp has not changed (and wont change), so it will always meet the where clause criteria.

Should there be an some additional criteria in the Where clause so that if the Opp has not changed, it does not try to retrieve it again? Since this is a scheduled flow that runs daily...

[tony-jones-tanium]

Hi Jame - I went ahead and updated the Rollup record so that the Full Record Set checkbox was true, however, when the scheduled flow ran again this afternoon, we can see that a large amount of Accounts had the value of the rollup field set to $0, then back to the original number: 

[jamessimone]

@tony-jones-tanium OK well - hardly the desired outcome, but an interesting and helpful data point nonetheless. Apex Rollup only performs a single update to parent records. It doesn't update parents to reset them prior to calculating what the updated value should be. This behavior strikes me as extremely unusual, as a result. I'd agree that your rollup setup seems extremely simple, but are there other automations running from Opportunity to Account that might also be acting on these fields?

I'm going to be looking into this as soon as possible - just looking to gather any other info that might be helpful along the way. Is there anything else you can tell me about how the scheduled flow is creating/updating opportunities, and how that ties into Apex Rollup being invoked?

[jamessimone]

For what it's worth - using a "simple" update scenario (with or without the Is Full Record Set flag), I'm not seeing anything like this behavior. Hopefully we can work together to figure out what it is about this set of automations that's producing this result for you!

[tony-jones-tanium]

Hey James! For the fields, fortunately, there is not any other automation running on the Booked ARR (Exit), purposefully, so that its only set by the rollup. The Max_End_Date__c, is a Rollup field of the Opp Line Item End Dats. And the the Closed Won field, well, it has not automation around setting or changing that field.

As for the Scheduled flow, its set to run Daily for around 10 different Rollups, that are separated into different Apex Actions, based on business need. Several Apex Actions have multiple Apex Rollups in them, that are separated by commas (The Apex Action for Booked ARR (Exit) has only the single rollup in the action):

[jamessimone]

@tony-jones-tanium I've created my own scheduled flow and rollup from Opportunity to Account to try to reproduce this issue, but so far I haven't been able to. With field history tracking enabled, I only see updates to Accounts where the rollup values weren't previously set. Is Sales Systems your default workflow user?

It'd be great to see a log with Rollup Logging Enabled for one of the batch chunks (or the RollupDeferredFullRecalcProcessor, if the number of accounts is less than what you have set up for Max Lookup Rows Prior To Batching on your Opportunity Rollup Control) that was generated by this scheduled invocation for that particular rollup. The only other thing I can think of at the moment might be possible when Should Skip Resetting Parent Fields on the rollup control record is false and a batch chunk only had non-matches for a particular parent and another batch chunk actually had children with values for that parent. You'd be able to tell this was happening - with some digging (Nebula Logger really comes in handy for such things!) - if there were two batch chunks where a parent was mentioned and in one of them it was getting reset.

That's truly an edge case that would require quite a few of your Opportunities tied to the same Accounts to "spill over" into different batch chunks; if that theory is correct, setting that flag to false on your rollup control would "fix" the issue. Might be worth a try.

[tony-jones-tanium]

Hi James - Attached is an export of all the Rollup Logs Entries from yesterday. I've tried using the Org Default Rollup Controller, but it errors out due to the batch size, which is why I have the custom Rollup Controller to minimize the batch size.

Looking at our sandboxes, Im seeing the same thing, where its setting the value to zero, when it shouldn't, and its not even resetting it back to the correct number.

Without being able to identify why its flipping the rollup to a 0 value, when the Rollup CMDT record clearly is a SUM of numbers that are greater than 0, it may be easier to just use a traditional rollup field.

Apex Rollup Booked ARR (Exit) 3.4.24.csv

[jamessimone]

@tony-jones-tanium I will take a look, I appreciate you providing that info!

[tony-jones-tanium]

Hey @jamessimone - Just wanted to let you know, I just updated the package in our Production environment, then manually ran the rollup and it worked as expected (only updated records where the amount would be changed and set nothing to zero). I will check back in on it Monday, but just doing an upgrade seems to have worked.

[jamessimone]

It's very possible that the latest release contained some improvement related to this issue. I apologize for the delay in response - I've been heads down working to release all of those fixes. Please keep me updated and hopefully we can close this one out!

[jamessimone]

@tony-jones-tanium just following up on this one, hopefully we're all good here

[tony-jones-tanium]

Hey @jamessimone - Sorry for the delay. Unfortunately, a few days after the package upgrade, the Apex Rollups reverted back to changing the values unnecessarily to an older value, before resetting them back (sometimes). Attached is a screen shot from some of these instances from the weekend.

With this field being a pretty important revenue field, we are moving away from Apex Rollups and converting it to a traditional Rollup Field (with some additional fields to get the accuracy in place).

[jamessimone]

@tony-jones-tanium no worries. I haven't observed this behavior - or had any other reports of it - so while I understand your decision, it'd be great to get some additional info if possible for me to investigate further