Category: Email Notifications
Posted by Mark Stanger in Email Notifications Wednesday, 11 August 2010 11:10 No Comments
H
ere’s a cool tip that was just sent to me by my friend Jim Coyne. We collaborated to solve a problem that he had in his environment and this post shows the result he came up with. This post shows how you can manipulate records in the email log (sys_email table) when you have a need to change the contents or recipients of an email record. This isn’t something that should be relied upon heavily and I would consider it basically a last resort but it can prove very helpful in solving the right type of problem.
The problem in this example was that there were emails being sent from Jim’s Service-now system that contained sensitive information. It was necessary to send this information as part of an integration with a 3rd party system but they didn’t want to retain that information in Service-now to be viewed in logs and in the activity history of task records.
Posted by Mark Stanger in Email Notifications, System Definition Thursday, 29 April 2010 12:50 8 Comments
I learned something new today while building out a few email notifications. If you’ve been around Service-now for a while
you’re probably familiar with the formatting of email notification messages. One of the common requirements for outgoing email notifications is to include a link to the originating record or task in the email. Doing this makes it easy for end users to return to the record that they need to work on. There are a couple of simple ways to include these links in the body of an email notification in Service-now. One way I’ve known about for a long time, the other way I just discovered.
Posted by Mark Stanger in Email Notifications, System Definition Monday, 12 April 2010 08:02 4 Comments
L
ast week i came across an issue where the system was 
receiving emails that we thought should have been classified as Forwarded emails and processed by a ‘Forward’ inbound email action. Even though all of the emails coming in had ‘Fw:’ as their subject prefix, some of the emails were being classified by the system as ‘New’ for their receive type instead of ‘Forwarded’ as we expected. After a little more investigation we discovered that the back-end code to identify forwarded inbound email actually requires more than just ‘Fw:’ as the subject prefix. The inbound email was being classified correctly because it didn’t meet all of the criteria for a forwarded email. This article contains a summary of the classification criteria for inbound emails. It should come in handy if you’re wondering how Service-now distinguishes between New, Reply, and Forwarded emails.
Posted by Mark Stanger in Email Notifications, Scripting Friday, 12 March 2010 11:01 No Comments
I
t’s very common to send out an email notification at different stages of a task. There are great example notifications out-of-box in the Service-now platform that show you how to set these up. In some cases, you may wish to send more than the standard information in your email. The ‘mail_script’ tag can be used to do some more advanced script processing and then print out the results using the ‘template.print’ command. Here’s a sample script that you could use in an outbound email notification. The sample script is designed to send out information about a particular task. It also includes a ‘mail_script’ function to perform some advanced processing and include links to all of the associated attachments for the task. This script can be pasted directly into the ‘Message’ field on an email notification or email template record.
Posted by Mark Stanger in Email Notifications, Scripting Friday, 8 January 2010 11:35 3 Comments
A
while ago I was asked by a client to help them get set up with the Service-now Subscription-based Notification plugin. I had previewed the functionality but really hadn’t worked with it very much. As I dug deeper I realized that the standard setup wasn’t going to work for them. Subscription-based notifications are really not intended to be used on a bulk-subscription basis. The idea is that you might pick a handful of CIs that you are interested in and subscribe to them.
The needs that my client had brought to light the following questions:
1How can I easily subscribe to multiple CIs without having to click through the creation of a single subscription record for each CI? If I want to subscribe to the 50 network devices I’m responsible for I don’t want to have to set each of these up one-by-one.
2How can I use CI subscription notifications and not spam the end-user with a notification for each CI? An example of this would be a system administrator who is responsible for a cluster of web servers. A configuration change on one of them typically means a configuration change on all of them. We don’t want to be sending the admin an email for each of the 100 servers every time an update is made to the change ticket.
Shown below is the solution that we came up with…
Recent Comments