Send Email for Error Logs

[fentes]

Hey Jongpie,

we are logging quite often and the logs are very helpful at debugging stuff. The issue we are facing is, that we need to look into the Logs/Dashboard in order to see that there was an error.

For many other issues like flow errors or Apex exceptions we are getting an email to a shared email inbox and then someone of the team investigates into that. So we are quite good if something really breaks, but there can also be some things which are business wise wrong but executed successful. We would see it if, we look into the logs, but pulling is not as reliable than pushing 😉.

To solve this gap, I want to send an email to the team whenever a Log was saved which contains an error. I saw that you already created a class called LoggerEmailSender to send an email if something within the framework crashed. I understood the documentation that its purpose is only for crashes. Can we maybe reuse the class for sending additional emails?

Wanted to ask about that before I write a custom trigger to send emails by myself.

[NX-Mirco-Centrone]

I am having trouble setting up a plugin for that. i don't know if i am doing something wrong. But im unable to retrieve Log records from the Logger.Triggerable interface.
I tried the Flow implementation too. Same problem.

And for the record, the documentation for the plugin into the "Readme" is outdated.

[jongpie]

@fentes I like the idea of reusing/extending the user of LoggerEmailSender to send notifications for error logs - I think there are a few orgs that would be interested in this feature. I've created issue #348 to track this enhancement - I'll probably have it disabled by default, but any orgs that want to receive email notifications will be able to configure it using custom metadata records (probably 1 custom metadata record to enable/disable emails, and 1 custom metadata record to specify the email recipients).

Let me know your thoughts on this approach!

[fentes]

Hey @jongpie
good timing. I installed the latest update with the Log Retentions Rules on production yesterday. For today I wanted to see how I could write a trigger for the emails 😊

I saw now (maybe it was there before) that there is a Logger Settings page. From a user perspective, I find it easier to manage stuff here than via Custom Metadata Records. You probably mean LoggerParameter__mdt ?!

But basically a simple checkbox to enable and a text field for email addresses is enough. Eventually it could be possible to do without the checkbox and just check whether email addresses are stored.

[jongpie]

hey @fentes, yeah, the Logger Settings tab was introduced in v4.6.14 - I think it's turned into a pretty nice page 😄

As far as using LoggerSettings__c versus LoggerParameter__mdt....

• I was originally thinking of using LoggerParameter__mdt (custom metadata object) to configure 1 or more email addresses that would be notified for any errors (up to 131,072 characters, based on the field LoggerParameter__mdt.Value__c). This would only have to be configured once in each org (and you could deploy the custom metadata record between orgs if desired).
• If I used LoggerSettings__c (custom hierarchy settings object), then you would still be able to configure 1 or more email addresses, but it would be limited to 255 characters (the max field length supported for custom settings objects), and the records would have to be configured in each org (you can't deploy custom settings records like you can for custom metadata records). This approach would also allow you to configure the email recipients at the organization, profile, and user levels - meaning that error logs from different profiles/users could be configured to notify different email recipients.

Let me know your thoughts on these 2 approaches - I think now like the idea of using LoggerSettings__c, but both options have pros & cons.

And as a side note - let me also know if you have feedback on the Log Retention Rules plugin! I don't think many orgs are currently using, so I'd love to hear any thoughts you & your team have about it.

[fentes]

Hey, I can only say about our org. We want to have email notifications only for production. If the setting is stored in metadata types, it will be copied during Sandbox refresh, so we probably get spamed from all Sandboxes 😅

255 characters is the theoretically longest possible email address. I googled about the average length and there was an article saying that 40-50 characters is a good number. Mine is 30 characters and the longest german address is 60 (from german military service, yep found a funny article about that). So with 255 you can handle about 5-8 different email addresses, which is from my opinion enough.

About retention rules I will write more feedback on the other conversation. So far it was good to run the purge job. Already took 2 hours with about 550000 log entries😅. I'm currently setting up the rules and it is quite annoying work, cause we need to have 3 metadata records for each rule(main record + 2 conditions). For now we need about 60 different rules so 180 metadata records. I saw a different repository of you to save Custom Metadata Type with apex, this might help.

[jongpie]

Thanks for the feedback @fentes! I'll look into adding a field on LoggerSettings__c to store the email address - it will probably be several weeks before I have time to work on this, but I'll keep you updated.

And I completely agree about the annoying work with setting up the custom metadata records - the Saleforce UI for custom metadata records is still not a great experience, so it's tedious to configure the rules initially. I unfortunately don't have a useful suggestions right now, but I'll try to consider ways to make it easier to setup log retention rules. If/when you have other feedback for the plugin, definitely feel free to start another discussion about it!