How do I disable DLRS emails?

[blarimer3]

Every now and then DLRS sends an email detailing why a rollup operation didn't work as of the last version or so. This seems to send out every single time an operation fails. Tonight, after-hours, such an email was sent about 20 times per minute in our org. This single-handedly ran us through our daily-allotted 5k apex emails today, and now this limit is making it impossible to make deployments as scheduled since some of our test classes cause test apex emails to send. This is a huge strain.

I can't find any way to throttle or disable these emails in DLRS. Are there no settings or ways to hamper this?

[aheber]

@blarimer3, I realize I'm late to the party. If these are the emails I think they are they are not sent by DLRS but are in fact sent by the Salesforce platform anytime an apex transaction fails. There is nothing that DLRS could do to prevent them. If they are those emails then your users or processes are running into errors trying to interact with your system and are possibly getting upset, generating invalid data, or data saves are prevented from being successful and you're losing data.

None of those are good for you or your system and I would recommend finding the root cause and correcting the error. It might be a validation rule that needs to be adjusted or something else. Those emails should be useful for diagnosing the problem. Sounds like some of your other deployment items might also need the same treatment.

Again, this is likely not a DLRS feature or bug, it is a standard behavior of the platform that DLRS is unable to influence.

If you'd like some help diagnosing the cause and finding solutions I would recommend posting a portion of those emails to the Trailblazer Community Group for the project. There are some wonderfully talented people there that are always willing to dig in and help. https://success.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F9300000009O5p

[blarimer3]

These are definitely package-generated emails - it only started happening after I had somewhat recently updated the DLRS application, prior to which it never occurred. They are not the typical apex exception emails, which are only sent to users specified in the Apex Exception Email settings in setup, but rather are sent to the running user of the rollup jobs, which in our case is not a specified apex exception email user.

The subject line is "Apex job 7074o00004kbYsAAAU failed to update rollups" which is markedly different than system exception emails which start with "Developer script exception from [org name]" and then go on to list the error message. System apex emails also provide a user ID / org ID, name of the failed class, and a stack trace in the email body, none of which are present in these emails.

The body of this email is much more simplistic as it only appears to capture the error message without the rest:

"Error: Record Currently Unavailable: The record you are attempting to edit, or one of its related records, is currently being modified by another user. Please try again.. Parent record Ids 0016A00000aeHHeQAM,0016A00000aeHHfQAM..."

I've attached a sample of this email.

I should also point out, these emails send every time a rollup error occurs (which is a core part of the frequency problem), whereas system apex exception emails only send once every so many exceptions. And finally, exceptions during the rollup process are caught as the rollup updates are set to allOrNothing = false, so there is no unhandled apex exception as far as the system is concerned. It seems that this recent upgrade to DLRS must then iterate over the failed updates in the transaction to send out some apex-based emails, presumably because allOrNothing being set to false means that users are not natively aware of failures - I imagine Andy must have decided at some point that these errors needed to be surfaced by the application.

To reiterate, I'm not trying to resolve the root issue reported in the email. I am only trying to find a way to disable or at least control these emails in some way. If it were a system-driven exception email this would be as simple as removing this user from receiving apex emails, but they are already not listed to do so. There is no current issue that's causing an influx of these emails as there had been when I reported it, but if something like this comes up again, what I really don't want to happen is to hit an email limit as this is a much more significant problem than the root issue.

[afawcett]

THanks for raising @blarimer3 they are packaged based - we can easily add a custom setting to disable them - but what would be your thoughts on how to receive them otherwise? I'll make this as a priority fix. Look forward to your thoughts on best design for this feature given your situation. Thank you!

[blarimer3]

Hey @afawcett thanks for getting back to me. My thoughts on this are two-fold:

1. In our own use case, we haven't found these emails particularly useful, so a setting to disable them entirely would be fine for us. We tend to identify the reported issues through other means anyway.
2. Speaking more generally from an app development perspective, a good in-between setting may be to create failure logs (via custom object) each time this happens, but only send out an email if that particular error message hasn't already been reported via email to the user in the last X hours (perhaps X could be a user input via custom setting). When an email is sent you could mark that particular log as "emailed user" so the system could keep track of when an error was last reported. That way if there is a repeating offender such as was the case for us, the user would theoretically be notified every X hours so long as it remains unresolved instead of each and every time. I think if you were to go this route, these logs should self-delete after so long so as to not overly-consume a user's data storage.

Thanks!

[jhillstrom]

I'm also swamped by these and there's not enough information in them to figure out how to prevent the underlying issue. I would like some more guidance in the error (or in the docs) on how to track down the problem.
I also really like @blarimer3's suggestion on how to make the errors less noisy.

[ClarkBranson]

I'm also suffering from this same issue and think I've narrowed it down to Aggregate Operations on Date fields (i.e., the most recent ClosedWon Date of an Opportunity up to the Account). However, if there are no records found meeting the SELECT filter criteria in the DLRS, it causes the "Apex job ... failed to update rollups" email to be sent. I suspect that, based on how it works with number fields that will change from NULL to "0," that if no records are found, that a DLRS Job on a date field to find First/Max, etc. is trying to update the Aggregate Result Field (also a date field type) with "0" when no records are found.

[JodieM]

I too would like documentation how to track down these issues. I need to see the emails, but I don't know where to start with trying to fix the issue because I don't know which DLRS is causing it (eg I know the Parent ID but there are no scheduled jobs on that Parent at that time of day)

[shef2000]

@afawcett - I recently ran into a similar issue above. Did this ever make it into the plans for a custom setting to disable emails? This ate up our orgs limit very quickly with very little detail in the email that helped diagnose the issue with the rollups.

Wouldn't there also be a fix to make it not use limits, as these should be sending emails to internal users?

[coriobriensfdo]

@afawcett - I recently ran into a similar issue above. Did this ever make it into the plans for a custom setting to disable emails? This ate up our orgs limit very quickly with very little detail in the email that helped diagnose the issue with the rollups.

Wouldn't there also be a fix to make it not use limits, as these should be sending emails to internal users?

Hi @shef2000 Andy no longer manages this product as it's part of the Salesforce Open Source Commons program. The volunteers who manage this product review existing issues on a regular basis and prioritize the roadmap, but I'll flag this with them to take a peek. Thanks for commenting with your use case!

[aheber]

I'll work to get a custom setting added to disable the emails, I'll also add some additional logging statements to supplement the emails.

As for tracking down problems, I'll look at improving the emails a bit while I'm in there but can't promise what the outcome of that will look like right now. I'll have to review with the team.

For anyone that is having problems tracking down the source of these errors, see if there are any log records being created, often times with the same parent id on them. I know some kinds of errors already generate log records in addition to the emails.

[shef2000]

Thank you @aheber and @coriobriensfdo! All admins will rejoice who encounter this issue eating up their limits.

The error message and content are super helpful. It's just the volume of messages that eats up the limits and potential disrupts other important parts of the org that is the issue.

For me, the root cause ended up being because some of the saved "relationship criteria fields" had been removed in the org. Unfortunately it doesn't appear to validate this on load, so it took trying to "resave" the rollup to figure this out at a glance.