Summary

This blog shows an alternative way to use HTML email templates in Oracle Sales Cloud Object Workflows, with the potential to reduce the number of workflows and templates that need to be maintained.

Introduction

One of the Actions available in Object workflows in Oracle Sales and B2B Service is Email Notifications. This enables the sending of emails to specified recipients based on conditions being met in the triggering object. The layout of emails is defined in plain or HTML Email templates which can be created in Application Composer, or using any email editor.

Email templates contain field references that are populated with field values at runtime. For example, a typical email template for Opportunity might contain the line:

Opportunity [$Name$] has been updated by [$OptyLastUpdatedBy$]

Email Configuration

While modifications to email templates do not require a software release, if either the workflow conditions change, or if a new template is used by a workflow action, then a sandbox needs to be created and published, and then the new configuration needs to be deployed. 

Most email templates use field references in the main body of the email, as illustrated above. This works fine when the "boilerplate" text is the same, but does not work with variable text. When the main template is different, the standard practice is to create another template, for example:

Template #1:     

The Sales Stage of opportunity [$Name$] has been updated to [$SalesStage$] 

Template #2:     

Opportunity [$Name$] has been closed by [$OptyLastUpdatedBy$]. 

The above would require 2 different workflow conditions, and the appropriate template would be associated to each condition. 

An Alternative

Instead of embedding object values into the body of the email, the values can be embedded elsewhere and the variability achieved by using HTML and CSS.

For example, the following body template embeds the runtime values into the CSS:

This text is displayed if the opportunity is open.


Different text for a different status

This will render either the OPEN div or the WON div depending on the runtime value of [$StatusCode$]. Clearly, each div can also contain runtime variables as with any other "standard" template.

Conclusion

This technique only works with HTML email clients, so it is probably only "safe" to use for internal notifications where you have control over how the email will be displayed. However, if you have lots of Object Workflows and many templates with minor differences you may want to consider this technique to push some of the conditionality into a smaller number of templates.

The key points to understand is that runtime values do not need to be used in the email body, and that variability can be achieved by using other HTML capabilities.