Email Template Expansion

Hello,  I have a fully working application and was able to get Email Template Module to work. But now I have come to a point where I need to develop better way to manage email templates via Admin pages.  My Current Configuration:   Where the retrieve activity retrieves the template by name and passes on to the SUB microflow as one of the parameters. This is all working fine as long as I have the correct template and name defined in the email template module. What I really want to do here is that not retrieve the template by name but retrieve them based on the trigger action. Consider this example: Create a template with any name In the template define a trigger action when this email template should be used. For example, when a new user registers in the app, the admin should be notified via the email. So trigger action action would be when user clicks Register button on that specific page.  This works when I define the template name ahead of time in the microflow and use the same template name when I create the template through Admin pages I do have a way to add additional attribute (i.e. ENUMERATION) in the Email Template Entity and this will solve my problem but this will require touching Email Template Module downloaded from the app store which is not recommended incase the the app store module is updated, I will lose my changes.   Any ideas?
1 answers

Maybe I’m not familiar enough with your problem but I don’t see the value that you add by allowing Mendix to find a template by enumeration value as to specifying a string value to retrieve a specific template. Maybe you gain a bit in terms of governance but you really should only have developers/semi-technical resources touching this side of the app that are aware of the repercussions of changing a Template Retrieve’s query parameters.

If anything, I would create  Sub Microflows named after the email functionality (ie. SUB_Registration_SendEmail) that perform the necessary template retrieve and send the queued email (First two actions in your screenshot). This creates a single piece of reusable logic so that whenever you need, you can place it within a trigger’s Microflow or Nanoflow to perform the logic in a standardized fashion. This approach also allows you to expand in the future by adding input parameters which will help standardize the information you might need to send that email if you find that you need specific information to replace as tokens in said email.


With that being said.  If this functionality is actually required by the business. A common practice amongst more enterprise clients is to duplicate the module. This allows you to modify and maintain the module without fear of it being overwritten by updating the original module. Looking to the future – If something breaks in the module due to a new release. The Email Module with Templates is published and maintained by Mendix to work with each release. Although sometimes pretty technical, you can poach the updated functionality and bring it into your company’s module and make the fix. (New branch for that kind of work would be a good idea)


I can’t say I necessarily recommend this approach unless it truly is required by your Organization/client. Although you may get the functionality you feel you desire. It also increases operational overhead for the application and your development team as the module grows.