Is it a known thing that we should use the underlying contact fields if we need to roll up to a person account? I spent some time troubleshooting an issue with a rollup and that turned out to fix it, but I would have expected it to also work using the Account as the parent object and the __pc field.
@Amanda Styles can you give more details on what problem you ran into? It might help us to be able to explain the underlying cause.
I am having issues with my org's Number of Big Give DLRS, which I inherited upon joining the company. There are 57 outstanding scheduled items that have failed to process and I do not know how to process them. I tried to re-calculate the job but this did not process the outstanding items. The DLRS appeared in my list of Apex Jobs but there doesn't appear to be any mechanism to push the 57 items through. Any advice much appreciated.
The full recalculation jobs don't clear scheduled items at this time. (We do plan to change that in the future)
If you have the RollupJob Apex class scheduled and it still won't clear the 57 items it could that they are for records that were deleted in the past and they weren't processed soon enough so those deleted items can't be found. (Happens a lot when the Scheduled Item job isn't run for a while)
You could investigate by looking at the DLRS Logs object, it should report why any given parent record isn't able to be updated and you can correlate that with the Scheduled Item records that won't clear.
If it were me, if you've run a recalculation already then you can be confident that everything is correct. Delete those outstanding Scheduled Item records and just make sure it stays clear going forward. Probably not worth a deep-dive investigation unless it really bothers you and you want answers.
I’m running into an issue with DLRS rollup summary calculations involving a hierarchical account structure, and I’d appreciate some guidance.
Scenario:
Each of these accounts has multiple related Policy records. I’m using DLRS to calculate rollup summaries (based on a lookup relationship) to aggregate values from the Policy records.
Expected behavior:
Actual behavior:
Observation: It seems like the rollup process is overwriting or recalculating values for related accounts in the same hierarchy, rather than maintaining independent aggregates per record.
Questions:
Any suggestions on configuration or best practices would be greatly appreciated.
Thanks in advance!
Hi Archana,
DLRS normally calculates a rollup for the specific parent record returned by the relationship field. It shouldn’t reset sibling Account rollups simply because those Accounts share the same parent, so I’d first look at the configuration rather than treating this as expected hierarchical behavior.
I’d check these areas:
A clean pattern is usually to have one rollup for Policy → Account (giving each Family its own value), and a separate parent-level rollup that aggregates the intended child Account values. Avoid having multiple rollups write to the same target field.
If you can share the DLRS configurations for the Family and Parent rollups (Relationship Field, Relationship Criteria, Field to Aggregate, Target Field, and Calculation Mode), it should be possible to pinpoint where the reset is coming from.
Hello,
I am looking for some support on how to review and manage the error messages I am receiving related to the DLRS jobs I currently have scheduled that seem to be 'bumping' into each other.
The two error messages (related to different scheduled jobs) I am receiving are:
1. Error: A calculate job for rollup 'XXX' is already executing. If you suspect it is not already running try clearing the applicable record from the Lookup Rollup Calculate Jobs tab and try again. Review the error, rollup definition and/or delete the Apex Scheduled job under Setup. Check if the rollup still exists via the Manage Rollup Summaries and/or Lookup Rollup Summaries tabs.
2. Error: You've exceeded the limit of 100 jobs in the flex queue for org XXX (sandbox). Wait for some of your batch jobs to finish before adding more. To monitor and reorder jobs, use the Apex Flex Queue page in Setup. Review the error, rollup definition and/or delete the Apex Scheduled job under Setup. Check if the rollup still exists via the Manage Rollup Summaries and/or Lookup Rollup Summaries tabs.
We have multiple jobs that are scheduled to run on the Opportunity spaced out by 30min but I did also receive error message 1. for a job that is scheduled on the Contact and Tribute.
When I review the Lookup Rollup Calculate Jobs, I see 14 jobs with created dates in the past (12/31/2025 and 01/01/2026). I have deleted these and will wait to see if they show up again after the nightly scheduled jobs run.
The Apex Flex Queue looks to have quite a few that are all related to RollupJob from 12/31/2025 and 01/01/2026.
Any suggestions to try or ideas on how to fix this would be greatly appreciated!
When high-volume objects like opportunity, contact, and tribute have multiple rollup calculations scheduled just 30 minutes apart, the initial batch jobs often take longer than their allocated window to complete.
As a result, when the next scheduled job triggers, it attempts to queue another batch for the same rollup, triggering the first error because the previous operation is still active
Hello,
I am with Rollup Helper support and I can confirm you can use dated exchange rates with our tool. You can have up to 3 Rollup Helper settings on the free version of the tool.
We would be happy to set this up with you over a call, you can sign up for a timeslot on our website here:
https://www.passagetechnology.com/any-product-one-on-oneWe have v 2.23 in both sandbox and production and attempts to install v 2.25 in a sandbox are returning an error saying it is a beta version and must be uninstalled. We have a DLRS heavy installation with over 100 rollups across multiple objects. Do we really need to uninstall? If so, what is the quickest way to manage this with all of the related triggers? Thanks.
OH!!! I see. You currently have a Beta installed. You can't upgrade FROM the beta to anything else. At some point you installed the beta version and now that sandbox won't move forward unless you uninstall or refresh it.
That makes complete sense. Unfortunately if you need that sandbox you wouldn't be able to upgrade it. You would have to remove and reinstall.
If you do need to save that sandbox and don't want to refresh then you can remove the DLRS Custom Metadata Records and the Triggers and Test classes. Uninstall DLRS. Then reinstall with the v2.25 link. You could then bring everything else back as a Changeset or something else from another Sandbox. (Or you could backup and re-add those elements through whatever your preferred Metadata management process is)
Check out the updated DLRS cookbook! You can now search for rollup recipes based on the calculation mode or operation. While you are on the site also check out the user guide
for detailed explanations of specific fundtions like calling a DLRS rollup from a flow or how merging is handled in DLRS.
Thanks for everyone at the August Commons sprint who contributed to these updates and an extra thank you to
@Kyle Broeckel for leading the DLRS documentation.Wrapping Up the Virtual Community Sprint!
We were thrilled to gather online on August 11-12, 2026 for two days of collaboration, innovation, and community!
122 attendees joined us, representing an incredible array of folks working within the Nonprofit and Salesforce ecosystems, End Users, Administrators, Developers, Architects, and Industry Partners from around the world.
To everyone who joined and gave your time...thank you. Your commitment to building together is what makes this community so powerful.
Ready to dive into the full recap?
https://sfdo-community-sprints.github.io/docs/sprints/2026/2026-08-1112-Sprint/
Couldn't attend the Virtual Sprint? Join a future event! See what's next up for the Nonprofit Community Team:
@Nonprofit and Education MindShare
@Commons Project: NP SF How-to Series
I'm testing out an upgraded version of DLRS in our Sandbox and reviewing our setup. A consultant set up all of our scheduled DLRS under the older version of "Process Builder" which is now "Invocable by Automation" in more recent versions. These were never tied to a process builder or flow, only scheduled jobs. I'm trying to understand the difference between a scheduled job of "Watch for Changes" vs scheduled "Invocable...". Does Watch for Changes only pick up child records that are created or updated and Invocable is always a full recalculation?
Invocable by Automation means taking control of timing and change detection. Best used with Flows or Scheduled Recalculation. Invocable by Automation disables all the "proactive" parts of DLRS for that rollup. Something else has to tell is that it is time to recalculate.
People will often drive DLRS via Flow when they need advanced criteria to know when a record should force an update, or because they want to use an async path to cause the rollup to update. (usually faster than Watch for Changes)
Scheduled Recalculation isn't really a "mode" by itself. It is the bulk reconciliation process. Paired with Invocable by Automation means DLRS only recalculates when told and that recalculation is across the entire dataset, not focussed on only those records that need to change. You can also use this with other modes, such as Realtime. If my Relationship Criteria uses a related object or relative dates (such as THIS_MONTH) then I need a Scheduled Recalculation as a backup to run once in a while and make sure all the values are correct. Realtime and Scheduled can only evaluate records when they are saved, if the change is isolated to the formula logic, or driven by a related record, then DLRS doesn't notice.
Realtime is usually best for when a rollup value MUST always be correct. If that field ever didn't match the data in the system it could mean real harm for your business. For most people this isn't the case but it still gets used often because people think they want it. As you've already figured out, Realtime is the most likely to expose errors because it adds the most processing work during the original record save so if it has problem or encounters something like a validation rule then DLRS will prevent the child from saving.
Scheduled/Watch for Changes is great for focussed updates that don't need to be immediate. It doesn't need to process every record in the system but can still delay processing for the RollupJob. This helps to separate the work that needs to be done from the act of saving child records. For most people this is good enough. It gives fewer errors to end-users and updates the rollup value when it is convenient. I usually recommend running every hour but I know many people need every 15 minutes. It is about how long you can go without the number being correct. Because errors are moved to a background job it becomes important to monitor the DLRS Log object, that is where most problems from here or the Scheduled Recalculate will show up.
Hopefully that adds more detail and decision points. There are a lot of ways to reach your goal. Usually I would recommend using Watch for Changes unless you have a reason to do something else.
Hi friends!
I have a weird one where records created by an integration user are not triggering the creation of "Lookup Rollup Summary Schedule Items" records for the scheduled rollup jobs to run.
I have tried adding additional permissions to the user including additional access to the parent/child records and various DLRS objects. The user has the Modify All Data permission as well as access to all the dlrs apex classes. I can't schedule the job with the integration user either to test that.
I'm totally drawing a blank on what else to check, so if anyone has any thoughts, I would be very grateful!
I'm not aware of any specific problems here. Can you give me any additional insight into how you have this user setup? Have you assigned any of the packaged Permission Sets to this Integration User?
I don't have a setup like this right now but maybe I can try and replicate it and test it when I have some time.
Normally if the Schedule Item record can't be written it will cause a failure during the transaction. It sounds like your records are correctly saving though. Is it possible your Integration User doesn't have access to the Custom Metadata records so it doesn't know about the configured rollups? I'd try assigning the built-in Permission Sets and see if that makes a difference.
