Best practices for the architecture of outbound notification mails

[onurg_l]

Hi,

may I ask if someone can explain what the best "architectural" way is to send email notifications? I am trying to create new email notifications but I don't get why there are email notifications and email templates when I can call scripts and create layouts with both. What are the differences (functionally and/or technically) between templates and notifications? What is the main reason to use notifications, templates, layouts and scripts? Are there more things other than notifications, templates, layouts and scripts that you can call or bind to a notification?

Thank you in advance !

Best regards,

Onur

[Dub Myers]

Hi Onur,

I would summarize as follows, with some trivialized examples:

Notification - Defines a specific notification with all its content, using static content, dynamic field references, or by mail scripting. If you want to share some of the content across notifications not using templates, you generally find you will duplicate content between notifications, and may require some mail script implementation to allow sharing.

Template - Allows content reuse within multiple notifications.

Example: You want a "P1 assigned to my group" style of notifications for each of problem, change, incident with subjects appropriate to the table.

1. Create template and define common body, using only fields from the common base task table in the template's email body

2. Create 3 notifications on the problem, incident, and change tables, each using the template

3. Override the subject in each notification to be applicable to table.   (e.g. "P1 problem assigned to my group", P1 Change assigned to my group etc.)

Note that in the template, you could use just WYSIWIG and the field picker to insert reference text, or could just use mail script in the template.   But in either case, the point is that you can only put content that makes sense for all three.   Since they are all based of off tasks and share common aspects, that is not that unrealistic as a scenario.

Layout - Layouts provide a quick way to implement static content reuse across multiple notifications.   (example:   Standard corporate header and footer)

Example 1: Simple notifications with standard corporate header/footer styling

1. Create a layout (Corporate Email Layout) with your static header images, ${notification.body}, followed by footer signature.

2. Create a template (Corporate Email Template) with no additional content, just linked to the layout you created.

3. Create multiple notifications referencing this template, each notification with their own subject and body.

You could do subsets of notifications, each with own workgroup header/footer styling as above.   In this case, you would do the above once for each workgroups 'standards'

You can also define CSS in the layout and reference it in your notification or template.   However, you should be aware that using CSS styles in this manner gives mixed results.   Some email clients don't support CSS styles and you may be better off using inline styles.

Mail Scripting and Layouts/Templates

Before Layouts, you could still produce this effect using mail script and either hard coding in the script, or having your mail script referencing some custom data representing your headers and footers and template.print your overall output.

Layouts were then later added so you no longer need to script the common static content like this.

With layouts, you design your standard HTML content for the static part, and just put ${notification.body} in the place where you want to see that notification's generated content inserted.

Notifications and templates are usually based around tables and content assumes that record type.   If you needed a notification to provide content across multiple records, and especially if they do not have references allowing dot walking, mail script would be necessary for you to query and find the appropriate content from each table, and then organize the output in the manner you want.

As with anything in ServiceNow, script lets you do a lot to customize exactly what you want when the system does not produce what you want it to. You can set subject, body, recipients etc via mail script.   Obviously when things go wrong, it is often harder to debug.   So try the non-mail script way of getting the outcome you want first.