Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: Schedule calculate - don't DML update record if rollup value unchanged #547

Closed
camisotro opened this issue Aug 21, 2017 · 17 comments

Comments

@camisotro
Copy link

I have a client who uses DLRS for an AccountTeamMember rollup to Account. It must run in Scheduled mode because a trigger is unavailable. They do have a number of baked-in processes including an external sync that get triggered by DML updates, even if the data is otherwise unchanged.

Every time the rollup runs, the "Last Modified" date on all 50,000+ Accounts is bumped, regardless of whether the rollup substantially changed anything. Apparently this causes a lot of difficulty for their automated sync. Would it be possible to add a setting which leaves the record alone without a DML update, if the calculated rollup is exactly the same as the current field value?

@afawcett
Copy link
Collaborator

Yes that would be possible.

@camisotro
Copy link
Author

Thanks - this would be much appreciated! If it makes it into a release I'll be sure to let my client know of the good news.

@camisotro
Copy link
Author

I guess this might be a dupe of #370 now that I see it? Save for, I suppose, the idea of making it an option. Under some scenarios it does make sense to trigger workflows and such en masse, but in others not so much.

@Bard09
Copy link

Bard09 commented Sep 27, 2017

I just logged a request for this same thing before seeing this thread. We would LOVE to see this change!

@afawcett
Copy link
Collaborator

afawcett commented Jan 1, 2018

Fixed in v2.10

@afawcett afawcett closed this as completed Jan 1, 2018
@camisotro
Copy link
Author

Awesome. Is this automatic in all modes or does it need to be enabled?

@afawcett
Copy link
Collaborator

afawcett commented Jan 2, 2018

It is automatic, only applies to scheduled full recalc (per wiki definition).

@camisotro
Copy link
Author

Thanks. I don't see any wiki entries updated more recently than May. For the sake of documenting to our clients who use DLRS, can you point me to where this is defined in the wiki?

@camisotro
Copy link
Author

Right I saw that page but it was last updated 13 Jun 2017, before I opened the issue, so I wondered if you were referring to other docs that you'd updated on the latest release.

I think I see the source of my confusion though, I thought you meant that the wiki specified the new behaviour.

@afawcett
Copy link
Collaborator

afawcett commented Jan 6, 2018

Ah no worries, hopefully the enhancement is performing well for you. Let me know if not.

@camisotro
Copy link
Author

I haven't had a chance to test it out yet at scale as our busiest projects this season are not with clients who use DLRS. The client who reported this as a concern is currently on an as-needed support contract with us so I will bring this up next time we are working with them actively. But thanks again for the help and I will be sure to report any feedback we come across.

@camisotro
Copy link
Author

camisotro commented Jan 8, 2018

I can report that in an org where running a calculate job would churn through 55 batches with various triggers and workflow rules involved, a full recalc took 3 minutes on 2.09 and under 30 seconds (knowing full well that almost all records would get skipped due to no value change) on 2.10. Cutting down the number of DML writes will probably have a positive impact on large recalcs for most orgs that have even one workflow/process/trigger on the object. Thanks again!

@camisotro
Copy link
Author

camisotro commented Jan 18, 2018

Had a rollup-related support question today from the client who led to me submitting this issue. I took the opportunity to upgrade them to the new DLRS, as solving the issue would have required a recalculate job. I can report that it's working as designed: After 506 batches had been processed, less than 100 records were actually modified because only those had a change in rollup value. The whole thing ran quite efficiently, down from 13 minutes in duration to 4.

@afawcett
Copy link
Collaborator

afawcett commented Feb 3, 2018

Thats really good news! Thanks for the feedback.

@ClarkBranson
Copy link

Is it still possible for the rollup summary to cause an update even if the value is unchanged? Use case: my non-profit customer is performing MAX aggregate to return the most recent Opportunity Close Date. Then Process Builder runs on edit to evaluate if the most recent Close Date is = This Month to check/uncheck a "Monthly Donor" checkbox. If the most recent Close Date = 10/1/2019 come 11/1/2019 when the Scheduled Calc runs, it's not updating the Parent record to fire the Process Builder to uncheck the "Monthly Donor" checkbox.

@camisotro
Copy link
Author

@ClarkBranson perhaps your use case can now be satisfied with the new Winter '20 Scheduled Flows feature. You can have it search nightly for records matching certain criteria and then run a Flow on them.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants