Issue with Scheduled Rollup Job Not Updating Records

[jithishakn]

Hi,

In our project, we are linking Case records with both the Account object and the Healthcare Provider object (a Health Cloud standard object). We have a requirement to:

• Calculate the total number of Case records linked to each Account and Healthcare Provider.
• Track the number of Cases created in the last 30 days for each related record.

When we run the rollup via the Recalculate Rollup page, the records are successfully updated — however, it takes approximately 9 hours to complete the update for all records.

As per our requirements, we need to keep this data updated on a daily basis. To automate this, we attempted to schedule the rollup job using the following anonymous Apex code: Rollup.schedule( 'Case Rollup All Case4', '0 13 16 * * ?', 'SELECT id FROM case', 'Case', null );

While the job is getting scheduled successfully, we’ve observed that no records are being updated as a result of the scheduled run. We're unsure if we're missing a configuration step or if there's an issue with the scheduled execution context. We would greatly appreciate your guidance on:

• Whether the scheduling approach is correct for this use case
• Any best practices or considerations to ensure rollups run effectively on a schedule
• Suggestions to improve performance for high-volume rollups

Please let us know if any additional information would help in troubleshooting this.

Thank you for your support and for the great work on Apex Rollup! Thanks, Jithisha K

[jamessimone]

Hey there,

Just looking at that select statement for your schedule, there's nothing obviously wrong with it, other than that it probably is quite a large amount of records to be processing. When it comes to the two rollups you're talking about:

Calculate the total number of Case records linked to each Account and Healthcare Provider

I don't see why this one wouldn't simply be accomplished using an ongoing rollup; in other words, why would you need a schedule to accomplish this? If you're calling Apex Rollup from your Case trigger or a Record-Triggered Flow, it can keep that amount in sync for you in an ongoing basis without any schedule at all.

Track the number of Cases created in the last 30 days for each related record

For this one, I would recommend using a schedule that contains a date literal (e.g. SELECT Id FROM Case WHERE CreatedDate >= THIS_MONTH) as it will sharply cut down on the records that you need to recalculate. You might find this a bit easier using a scheduled flow that calls the Full Recalc Comma-Separated Rollup DeveloperNames rollup action with the dev name for the CMDT associated with this rollup. I think that would be a cleaner approach, overall.

Let me know if that helps!

[jithishakn]

Hi ,

Thank you so much for the input.

Just to share a bit more context, for the second rollup (tracking Case count in the last 30 days), I actually did go ahead and create a scheduled flow that calls the Full Recalc Comma-Separated Rollup DeveloperNames action. I’m passing in the API names of the relevant rollups as a comma-separated string.

As mentioned in the blog’s considerations for scheduled flows, I made sure not to define any SObject in the Start node — that way, the flow is bulkified and only consumes a single interview per batch, rather than per record. That part seems to be working fine in terms of efficiency.

However, what I’m observing is that only Accounts and Healthcare Providers that have Cases in the last 30 days are being updated. Parent records that don’t have any recent Cases aren’t being touched at all — which means their previously stored rollup values aren’t getting cleared or updated to 0, and that results in stale/inaccurate data.

When I run the same Full Recalc rollup manually from the Apex Rollup UI, all records get updated properly — including those with 0 recent Cases — so the rollups reflect accurate values across the board.

Is this a known limitation of using Full Recalc via scheduled flow without an SObject start? Or would you recommend a different pattern to ensure stale values get cleared?

Thanks again — this has been super insightful !

[jamessimone]

@jithishakn is your Should Skip Resetting Parent Fields checkbox true on your rollup control record? As far as I can tell, that's the only way that the older records which no longer meet the criteria you're using wouldn't get reset. Are you using a separate rollup control record for these rollups?

[jithishakn]

No, Should Skip Resetting Parent Fields is not checked. Please find the screenshot of the config done.

Rollup control

[jamessimone]

@jithishakn I've been doing some testing to try to reproduce the issue you're describing, including setting up a scheduled flow and a number of different comma-separated rollups to be invoked by that flow.

In my case, the first time the flow ran, I observed that the RollupParentResetProcessor successfully went off and updated some parent records that had not been included in the overall full recalc. Then, on subsequent full recalcs without changing the where clause, those records are not touched again and the RollupParentResetProcessor doesn't run. If I change the where clause to again make some of the parents not have any matching children, the parent reset processor will run once more, again.

Have you tried debugging your scheduled flow or setting up a trace on the automated process user with the Is Rollup Logging Enabled flag set to true on your rollup control record? Essentially, you should be able to observe two things:

1. A big log per "chunk" of children calculated (the number of chunks will equal the ceiling number of children records divided by the Batch Chunk Size pictured above on the rollup control record)
2. A smaller log afterwards whose first log message (filtered by "Debug Only" or by searching for instances of the line USER_DEBUG in the log itself) says "Rollup v1.x.x: Beginning finalizer with cabooses: 1" - then information about whether or not the parent reset processor has performed calculations will follow

Let me know if you're able to take a look at the logs that are produced - hopefully they will help shed light on what is going on here!

[jithishakn]

Hi,

We were able to resolve this issue by creating 2 separate scheduled flows to execute the 2 rollups in UAT. However, after deploying to production, we’ve noticed that when triggering a CMDT-based rollup via Recalculate Rollup, the aggregated values on the parent records aren’t updating correctly. For example, when querying the child records directly, the count is significantly higher than the value populated in the rollup field after recalculation. Could you please advise on what might be causing this issue, and how we might go about resolving it? Any pointers or troubleshooting steps would be very helpful.

Thanks, Jithisha K

[jamessimone]

@jithishakn my recommendation would be to:

• enable logging on the Org Default Rollup Control CMDT record
  • optional, but very helpful: if you don't already use Nebula Logger, install that and the plugin package for it here.
• start a single CMDT rollup recalculation from the app with just the rollup that you're seeing incorrect values for after the fact
• look at the logs generated by the full recalc run; either by using the Apex Debug Logs or the persisted logs through Nebula Logger. See if there are any warnings being generated; see if you can find any parent records pre/post rolling up that are reporting values incorrectly. If possible, upload one of the Apex Debug Logs associated with the chunk(s) where incorrect calculations were performed here to aid in further analysis

[jamessimone]

I am closing this issue - the fact that the rollups were working in UAT but not production is a strong indicator (to me) that there are dueling automations at play here, and such things need to be solved at a per-org level