Home > Forum > User Voice > SDK: Option to overwrite/extend notification actions

SDK: Option to overwrite/extend notification actions
4

MVP

Hi,

at the moment we have to decide whether we want to send a standard or custom notification (mail). While some users receive only a few mails this way, other receive to many and want to receive only a summary on a scheduled interval. While we can and have implement a configuration for an application on process level this is still limited and makes the automations less readable while the option to send a mail with a task can not bused at all.

My suggestion would be to provide an plugin/extension for the existing "send mail actions".
Provided options of the plugin:
- Current information of the context like, process, workflow instance, recipients, settings etc. Basically everything which is configured in the custom notification but not only for this but also for the "send standard notification" action.
- Option to declare that the action was already executed and no mail needs to be send.
- Custom /additional log message

This plugin could be selected on:
- Global level
- Per process
- Per workflow
- For a custom notification action

This would allow us to intercept all process related mails without changing the configuration itself with a lot of "if" operators.

Besides this one other major benefit would be that we can provide our own notification type for a process.
For example, we could define for a process that a "notification" is no longer a mail:
- We could send a Teams message
- Send an additional SMS
- Write to a custom database
- Call a REST API to store the "notification" in an external system.


I'm aware that this is not at least supported at the moment and you can achieve this already with the current options, but it requires a dedicated implementation for each mail instead of a general approach.

It may also be a stupid idea and I only came up with it as I'm also a developer at heart who tends to abstract more than necessary. :)

Best regards,
Daniel

MVP
In reply to: Markus Jenni

The described approach of intercepting outgoing notifications offers way more flexibility than our recently implemented PoC.

For this PoC, we implemented an SMTP-Server that is redirecting the standard e-mail notifications to MS Teams for internal recipients whilst external recipients still receive e-mails.

We thought of something similar but rejected the intermediate SMTP.

WEBCON has a queue for handling any errors when sending mails. We haven't tested it, but in our opinion the intermediate server adds another level of complexity and requires an own monitoring / error handling. Besides this, the mail would be marked as send in the history while it may has not been send.