Implement a more robust notification system

[Damecek]

Package Edition of Nebula Logger

Unlocked Package

Package Version of Nebula Logger

1.5.2

New Bug Summary

Hi,

currently the Configuration of the Slack Plugin is stored in the Custom Metadata Type called Logger Parameter. This brings complications in following cases:

• Package upgrade will overwrite current setting with the default one coming from package
• cloning sandbox from target sandbox will also clone the configuration of the plugin. this is issue especially for the SlackEndpoint metadata as this could let to multiple sandboxes publishing messages to a single Slack Channel

My suggested solution is to store those information in Custom Settings, which are not deployable. Another benefit of this would be that we could publish messages to multiple Slack Channels from single Salesforce environment. Could be useful for example to log System Admin Profile to different channel than the rest of profiles.

[jongpie]

Hi @Damecek! I've been having similar ideas over the last few months, and I think I'm going to...

• Make the Slack integration part of Nebula Logger's core package (and the Slack plugin will be deprecated)
• Use 1 or 2 custom objects to store configurations for notifications. I think that custom settings will be too limiting.

I've started a prototype of using custom objects, and it'll give me a lot more control & flexibility over how Slack notifications can be setup (including sandboxes with cloned data). I'm hoping to make more progress on this over the next few months.

[Damecek]

What limitations are you talking about? The benefit of custom settings is the hierarchy where different users or profiles can send messages to a different Slack channels. Also, using custom settings will be easier to integrate the slack setup to the current custom setup component.

[jongpie]

There are a couple of issues with using custom settings

• Cloned sandboxes will have a cloned copy of the custom settings data, so multiple sandboxes publishing messages to a single Slack channel would still be an issue. With custom objects, the data will still be cloned, but I can use some additional fields on the custom objects to track the original org ID where the record was created (and then not send notifications if the current org ID is different).
• Tying the notifications directly to the hierarchy is limiting. In my current job, we use Nebula Logger for monitoring multiple apps that we own. And often, we'd like to receive notifications for some of our apps/Apex classes, but not others - the profile or user is not relevant to which notifications we want to receive. Using profiles/users (via custom hierarchy settings) doesn't provide this flexibility.
• In more complex orgs, there is often a need to send notifications to multiple Slack channels. Some orgs are supported by multiple Salesforce teams, so sending Slack notifications to only a single channel is not ideal for some admins & developers.
• Long term, I want to support other types of notifications besides just Slack. Not everyone use Slack, so I want to move towards a more robust data model that will (eventually) support the ability to setup other integrations, like email notifications, Teams messages, webhooks, etc. This would be too complicated to try to do within the custom settings object.

By decoupling notification configuration from logging configuration, it'll provide a lot more flexibility.

[Damecek]

Thanks for explaining, it looks like you have everything though through. Definitely looking forward to this upgrade. 🚀

[Damecek]

Hello @jongpie really appreciating your work on this repository. I would like to ask how does it look with the Slack Plugin refactor?

Today I've received a request to send some specific logs to a different channel which is not currently possible. The use case was to separate logs around our SFMC integration to separate SFMC slack channel. This is not possible now, nor it would be easily possible with the Custom Setting I initially suggested. As you said they are too limiting and the Custom Object will be better suitable for this. Ideally we would like to define multiple slack channels per Log Entry. The Log Tags looks like good option, each tag could have it's own slack channel configured.

So I wanted to bring this back to your attention. Thanks in advance.

[jongpie]

Hi @Damecek great question, I should have added a comment on this issue a few months ago with an update:

• I have a design (and some prototypes) for the overall architecture/data model that will be needed to support the ability to define notification rules & conditions for sending logging notifications to Slack (and eventually other services, like MS Teams, webhooks, etc., for orgs that don't use Slack)
  • The planned design will support your situation of sending different logs to separate (or even multiple) channels
  • I'm planning for it to support using tags as one way to control which records to send to a Slack channel
• Right now, the architectural design I want to use needs a way to store & parse criteria to determine which records to send to Slack. To do this, I am planning to use the new FormulaEval namespace in Apex - but since the FormulaEval namespace/functionality is still in beta, I don't want to add this functionality to Nebula Logger yet.

So I'm definitely planning to implement this eventually, but I'm focusing on other enhancements & bugfixes until FormulaEval is generally available (GA) in Apex.