Customizing Email Templates for Workflow Notification

[Leela-Pavan-Kumar]

I need to customize the OOTB Email Template which is located in "/libs/settings/workflow/notification/email/default/en.txt" for Workflow Email Notification in a Participant Step.

I tried overlay it to /conf but changes are not reflecting. Even after restarting the bundles and instances.

As per the  Adobe documentation they are suggesting to change the OOTB template which is under /libs.

Is it ok to customize directly in /libs ? If not how to resolve this issue.

Please help me on this.

[arunpatidar]

Try to overlay at /conf/global/settings/workflow/notification/email 

[Leela-Pavan-Kumar]

Did the same thing, but its not picking up for Email Notification.

Restarted the bundle and instance after making these changes but still its not picking this

[arunpatidar]

If your requirement/solution/design allow then you can create custom workflow step for notification

example - https://aemlab.blogspot.com/2019/06/aem-custom-templated-email.html 

[Leela-Pavan-Kumar]

Here I just need to add few additional properties to OOTB Email Template.

Is there any specific reason why adobe is suggesting to do changes in /libs directly ?

And

Why even after overlaying the OOTB email template, it is not picking up ?

[arunpatidar]

This has to be answer by Adobe, I am not sure why is it not picking the overlay changes?

I think you can make changes in libs, only part where you can't are below

Content Classifications

AEM has long used the principal of overlays and Sling Resource Merger to allow customers to extend and customize AEM functionality. Predefined functionality that powers the AEM consoles and UI are stored in /libs. Customers are never to modify anything beneath /libs but could add additional content beneath /apps to overlay and extend the functionality defined in /libs (See Developing with Overlays for more information). This still caused numerous issues when upgrading AEM as the content in /libs might change causing the overlay funcationlity to break in unexpected ways. Customers could also extend AEM components through inheritance via sling:resourceSuperType, or simply reference a component in /libs directly via sling:resourceType. Similar upgrade issues could occur with reference and override use cases.

In order to make it safer and easier for customers to understand what areas of /libs are safe to use and overlay the content in /libs has been classified with the following mixins:

• Public (granite:PublicArea) - Defines a node as public so that it can overlaid, inherited ( sling:resourceSuperType) or used directly ( sling:resourceType). Nodes beneath /libs marked as Public will be safe to upgrade with the addition of a Compatibility Package. In general customers should only leverage nodes marked as Public.

• Abstract (granite:AbstractArea) - Defines a node as abstract. Nodes can be overlaid or inherited ( sling:resourceSupertype) but must not be used directly ( sling:resourceType).

• Final (granite:FinalArea) - Defines a node as final. Nodes classified as final cannot be overlaid or inherited. Final nodes can be used directly via sling:resourceType. Subnodes under final node are considered internal by default

• Internal (granite:InternalArea) - Defines a node as internal. Nodes classified as internal cannot be overlaid, inherited, or used directly. These nodes are meant only for internal functionality of AEM

• No Annotation - Nodes inherit classification based on the tree hierachy. The / root is by default Public. Nodes with a parent classified as Internal or Final are also to be treated as Internal.

[Leela-Pavan-Kumar · Accepted solution]

Here is the solution that worked for me!

The default email template for participant step is 

/libs/settings/workflow/notification/email/default/en.txt

Overlay it to this path and make the required changes here

/apps/settings/workflow/notification/email/default/en.txt

Restart the bundles/instance to reflect workflow notification template changes, since from AEM 6.4.0 all the templates moved inside the bundle.

[Timo_HH]

In AEM 6.5.20 the class com.day.cq.workflow.impl.email.EMailNotificationService tries to find the email templates first here:

String templateLocation = "/etc/workflow/notification/email/default";

 If this location does not exist, it takes '/libs/settings/workflow/notification/email/default' as default path.

So for overlaying the email templates to create custom emails, you can copy '/libs/settings/workflow/notification/email/default' to '/etc/workflow/notification/email/default' and adjust it there.
No service restarts required.

In AEM 6.5.20 this worked. For lower AEM versions please try on your own.

[Timo_HH]

"No service restarts required." is not correct. The folders are read during service activation. So the service/instance needs a restart.
Enabling a debug log for com.day.cq.workflow.impl.email.EMailNotificationService shows which folder is used during service activation.