Idea Summary
Add configuration options for apex_mail that allow overriding the Sender and Recipient of all emails for an instance or a workspace.
Use Case
When running an application in a cloned environment (whether a separate instance, or in a separate workspace) for development or test purposes, transactional emails must not be sent out to “real users”; emails sent accidentally can cause significant confusion and disruption in an enterprise which relies on emails for notifications and warnings.
Preferred Solution (Optional)
-
optional parameter at the instance and workspace level “EMAIL_FROM_OVERRIDE” that, if set, will replace the Sender of all emails sent by APEX_MAIL from that instance or workspace. This would allow emails to be sent but the recipients can use the Sender to identify where the email came from (e.g. “dev_system@company.com”) and filter them accordingly.
-
optional parameter at the instance and workspace level “EMAIL_TO_OVERRIDE” that, if set, will replace the Recipient(s) of all emails sent by APEX_MAIL from that instance or workspace. This would allow, for example, a developer to intercept all emails from a dev instance or their workspace, so they can test their application email behaviour without risking sending confusing emails to other people in their organisation.
-
optional parameters at the instance and workspace level - “EMAIL_HEADER”, “EMAIL_FOOTER”, which would be substituted into the body text/html of all emails sent by APEX_MAIL. Perhaps a suitable placeholder such as #GLOBAL_HEADER#, #GLOBAL_FOOTER# would be used to avoid mangling a html-formatted email.
Related: https://jeffkemponoracle.com/2019/07/wipe-apex-mail-queue/