Can a user manually edit and send notifications?

[DevHyfes]

I'm trying to figure out if there is a way for our Incident Managers to manually trigger "dynamically created" notifications that they can edit.

Right now it seems like there are only two ways to notify "interested parties" on a ticket- automatically generated notifications that can dynamically generate text with variables and javascript, and then manual emails with the "Email Button" from in the task. Here is my problem:

1) Notifications cannot be manually triggered without adding some element to the ticket that people change to fire the notification, and then those notifications cannot be reviewed prior to sending.

2) I can manually send and review via the email button, but that only allows Quick Messages that cannot use variables or javascript to generate text.

The problem is that we get some pretty complex incidents/outages at times where multiple (external) partners and (internal and external) customers are impacted. Not only is the information we share with each party different, but when they send us emails that get collapsed into the incident ticket, we may need to respond to the party individually. Right now, we have a field for (say) "Partner Update" that gets changed and saved, firing off the partner notification. Then there is an "Executive Update" that gets changed when we want to update our executives. So now we have these fields including Worklogs, Partner Update, Addtl Comments, Executive Update, etc etc that are each on the form solely to fire off a specific notification. If other fields are pulled from elsewhere in the ticket on these updates, the user is confused about which should be changed before making the update. And of course, if they need to communicate with only one executive or partner, they are forced to use the email button.

All I want is the ability to do something like "Send Partner Notification" and for it to pop up the email- pre-filled- for the assignee to edit prior to sending. But it doesn't seem like a hybrid of 1&2 above (manually triggered, dynamically generated) is available.

Has anyone dealt with this problem and solved it before? Absent any suggestion, my thought was that I would eliminate the business rules that fire these Notification events and instead make them all ui actions that popup a small ui that gathers the info, previews the info and then fires it off to the notification system. But this is a lot of trouble that would need to be done for each notification system. Is there a different way to address it?

[tltoulson]

To my knowledge there is no existing "Preview/Edit Notification Before Sending" capability in ServiceNow.   There are a couple of options you could manipulate to achieve the desired result:

Option 1: Manipulate the Notifications

My first choice would be to find a way to setup the Notification filters or Mail Scripts within the body of the notification to work with the existing work notes/comments fields.   If you setup multiple notifications, you could have one notification fire if the work note starts with "Partner Notification" and another could fire if it started with "Executive Notification".   Or you could setup a single notification that uses a mail script to manipulate who receives it based on the contents of the work note.   This obviously doesn't solve for the "preview" but does offer a way to remove the duplicate fields and still get the notification routing to the right people.   This is also the most out of box solution.

You could then use a UI Action to pre-populate the work note according to a template

Option 2: Custom Table

You could also create a new behavior in ServiceNow that allows the "Preview before Sending".   To do this:

1.   Create a table (Custom Notification for instance).  

2.   Add fields that you would need for this behavior (To, Subject, Body, Task/Incident, etc).  

3.   Create a UI Action that would popup the form of the newly created table (you could even use the Template application to create notification templates to pre-populate fields)

4.   Create a new Notification on insert for the new table (this is where the Task/Incident field on the notification could be useful for dot walking the fields to which the notification pertains)

The disadvantage is that this is quite a bit of customization.   The advantage is that this framework could then apply to other areas of your instance for other Notifications where you need the preview feature.

Summary

I would do everything possible to work with Option 1 first.   It is supported out of box.   Also, the Notification system is designed to be transparent so that technicians don't have to think about the communication.   Ideally it should happen seamlessly.   However, we don't live in an ideal world, so Option 2 is a more comprehensive solution to your requirements.

Let me know what you think, I will be happy to assist you further in finding the best solution to this issue.

[Slava Savitsky]

If you want a robust and scalable solution, go for the custom table approach outlined by @tltoulson. If it sounds too heavy, use UI actions to pop up a GlideWindow where you can write a message, add recipients, etc.