Email Test Group - Translated Emails

[Adam C1]

One very common way to suppress emails in a non-prod instances is to use the "Email Test Group".  This solution has been floating around for years, but is not officially supported.  

It involves a Business Rule on the sys_email table that checks a system property for an assignment group, and if user intended to receive the email is not in the test group, the email is not sent to them.    This allows email sending to be enabled in non prod, but the audience can be controlled.   We also use a Business Rule to add a note to the email to indicate its coming from a non production instance.

We have recently enabled Spanish language in our instance and our solution includes sending translated emails for those with Spanish sent as their language preference.  We have noticed these translated emails are actually handled by a different table Translated Email Contents sys_translated_email_content

These emails are bypassing that "Email Test Group" solution as it only targets the primary email tables, and being sent out unexpectedly. 

Has anyone had experience with adopting that Email Test Group solution to the translated emails or approached this a different way?

[Alex Coope - SN]

Hi @Adam C1, 

So firstly, that email practice is not best practice due to the numerous inherent risks of emails being sent to places it shouldn't as well as numerous (and various customisations). Even with putting warning text and trying to mitigate, it's still not a best practice.

On the "Email Properties" page, there is a specific property to be used as an override address (sends all emails to it) specifically for non-prod scenarios. 

[edit] - I tried to upload a screenshot but it keeps erroring.

I would instead use the property, then once the emails have been generated as translated (either if you are using DT or have pre-translated the notifications into the target language) you would then be able to see them in the email table when they are in the "sent" status,

Many thanks,
kind regards

[Adam C1]

I could see this as helpful, but we have an expansive platform covering many custom applications and modules that have various testing teams and testers (hundreds).  Obscuring the emails to a single mailbox or relying on access needed to view the email table could be problematic.   

Does the Email Properties maintain who the original audience would have been? Mail scripts often inject CC or BCC that may not have been the configured recipient from a notification perspective, if the true audience was being masked, then they can only validate that the email was sent, but not the audience.

[Alex Coope - SN]

Hi @Adam C1,

Typically the best-practice approach is to follow the steps here. If there's a need to allow multiple teams to review their emails, then what I've seen (alot) in the past is filtered lists of the email log table in the sub-prod to the various needs of those teams,

Many thanks,
kind regards