An updated solution can be found here - TNT: Attaching Shared Documents to an Email Notification.
Someone asked me how they could send an actual document with a notification and not just a link to it. That's pretty easy now, with the "Include attachments" field on the Notification record. However, in this particular case, the document was not being attached to a task or other type of record - it is a PDF document that contains the company's Terms of Service. They wanted to send the PDF out to users in certain situations, such as when ordering a catalog item.
So, instead of manually attaching the document to multiple records whenever it needed to go out, this is how it can be handled, limiting the amount of scripting and maintenance required.
Step 1 - Create a new Event in the Registry
Select the "Registry" module in the "System Policy" application and create a new record. I called it "u.terms.of.service" (remember to prefix any custom events with "u." in order to avoid issues with SN adding a new event with the same name) and set the Table field to "Knowledge [kb_knowledge]":
Step 2 - Create the Notification
Create a new notification, and set it to go out when the "u.terms.of.service" event is fired:
Make sure the "Event parm 1 contains recipient" field is checked as we will send the sys_id of the user in the event in step 4 below (you may have to switch to the Advanced view to see the field):
Make sure the "Send to event creator" field is checked as well to ensure the email will go out.
The important part of the notification is to select the "Include attachments" field:
Fill in the Subject and Message fields with whatever you want in the email message.
Step 3 - Create a new Knowledge Article
This step allows you to create a record that will contain the attachment(s). Create the article and attach the document to the record. I use the event name as the Short description. You can limit who can see the article by adding the "admin" role to the "Roles" field. You do not even have to publish the article in order for this to work, so only your admin and KB admins would even see it. You can also create a new Topic and Category combination for these documents if you want to separate them from all the other "normal" KB articles.
NOTE: You will need to export the article from your development instance and import it into production or just recreate the article in production as the KB table is not tracked in Update Sets.
Step 4 - Fire the event
This can be from a Business Rule or even a Workflow - all depends on the requirements:
(function() {
var gr = new GlideRecord("kb_knowledge");
gr.addEncodedQuery("workflow_state=published^short_description=u.terms.of.service");
gr.query();
if (gr.next()) {
gs.eventQueue("u.terms.of.service", gr, current.getValue("caller_id"));
}
})();
The script queries the KB table for a record with a Short description the same as the event name (or however else you may want to search for it). It then adds the event to the queue if it finds a record, passing along the event name, the GlideRecord object of the KB article (gr) and the user who should receive the document (current.getValue("caller_id")). You will probably have to change where you are getting the value for that last parameter based on your situation (my example is sending the email to the Caller on an Incident record).
The nice thing about doing it this way is you can easily update the attachment on the KB article record and the new document will go out from then on. The condition on line 3 of the script checks for a published KB article - that way you can retire the article and the notification would no longer go out because the event would not fire as the article would not be found in the query, all without having to change any code.
10 Comments
