Slack Plugin Config should be stored in Custom Settings

[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. 🚀