Create your own (parameterized) mailtemplates in IAM

Related products: Thinkstore

With the release of 2023.2, it will be possible to send mails based on templates via IAM. We have already built an email queue mechanism ourselves where emails are queued and sent based on (parameterized) templates via an SMTP connector. After learning that IAM would get a similar feature, we wanted to phase out this functionality and have it replaced by IAM. 

Unfortunately, in IAM we cannot use the templates ourselves, but there are only some standard templates which are used by IAM, which is not sufficient for our use case.

We would like to be able to create our own parameterized templates in IAM, which we can then call with a mail connector. The mail connector then needs a template code/name and necessary mail parameters (in json, for example) to create the body of the mail, by replacing the parameter placeholders in the template body with the parameter values passed in the mail connector.

This will enable us to automatically use the mail provider provided in IAM, and allow us to use translated mails in different languages.

Really love this idear, I would only want to add that you have to create the templates in the SF, just like the mail configs, and then they are adjustable per application in IAM. :)


NewOpen
 
Discussed with Robbert, the idea focuses on having an Email templates entity which is part of the model. These email templates should then be listed in the model, and can be used inside (a) new Process action(s). Also, this information will then be synchronized to IAM in which the email templates can be overwritten per application.

I get what you want, but I see one major disadvantage to this idea. When you use IAM to store which emails need to be sent (and as a log/archive which are sent), the data security lies with IAM. All system administrators can view the emails that were sent, including personal information. From a privacy point of view (GDPR or AVG in Dutch) this might undesirable. 

That is why I would recommend keeping a separate table to store and send emails from your system. Additionally, carefully consider which users or roles have access to specific data.

I would love to have a Thinkstore (base) model that gives you a standard solution for this while keeping it in your own model/database.