HowTo:Send Notification Messages to Followers

This code sample sends an email to everyone who registered themselves as a "follower" of a Case (or any other object where the application designer allows it).

To follow the record, a "related record" with the user's email address is added to the Followers object. When the Case (or other record) is updated, an email notification is sent to everyone who is following it, using an API and an email template created for the purpose.

Learn more:

• Related Records
• Email Templates
• SendEmailUsingTemplate (Java API)

Setup and Testing

1. Create the Followers object:
   • Launch the Object Construction Wizard
   • Define the fields: user_name, email.
   • Click [Save] and then [Create].

2. Create the linking field:
   • Go to > Objects > Followers > Fields
   • Create a new Multi Object Lookup field called related_to.

   Select the objects that can be followed, or choose All Objects.

   (The data in those fields has the format object_id:record_id. That's why you can follow any record in the system.)

   • Click [Save].

3. Modify the Case form to create a new tab that displays Followers.
   • Go to > Objects > Cases > Forms > Agent Form
   • Click [New Related Information]:

     • Object: Followers
     • Fields to Link: Followers Field: Related To, links to Cases Field: ID
     • Fields to Display: User Name, Email
       (App ID will stay hidden, as it is basically unreadable.)
     • Sort by: Email, Order: Ascending
     • Click [Save].

4. Use the sample code below to create the Notifications class.

5. Create a record-updated rule that invokes the notifyFollowers() method defined in the code.
   • Name: Send Update Notifications
   • Description: Tell anyone who is following the record that a change has occurred.
   • Run this Rule: Unconditionally
   • Actions to Perform: Invoke Method, Class: Notifications, Method: notifyFollowers
   • Click [Save].

6. Open a case record, click the Followers tab, and manually add yourself as a follower.
   • Fill in the user and email fields.
   • If you're in the ServiceDesk app, the app ID is easy. It's 1 (one).
   • Otherwise, leave the field empty and delete the record later. Or go to the Applications page to retrieve the ID of the current app.
7. Update the case record and check your inbox for the notification message.

Next Steps

Here are some things you can do after you get the basic behavior working:

1. Define a Follow macro for any object in which you want to add Followers:

   In that macro, invoke the addFollower() method defined in the sample code.

   The macro will appear in the list of actions available for the record.

   When clicked, the macro will add a Follower record, with all fields filled in.

   Here's what you need for the basic macro:

   Name: Follow

   Description: Add the user who clicks the button to the list of "followers"--people who will receive an email when the record is updated.

   Show: Always

   Action: Invoke Method, Class: Notifications, Method: addFollower

2. Send notifications for a subset of updates

   This is an extra credit assignment.

   To do it, you hard-code a list of fields you care about in the class. Or you could use the Functions.getFieldMetadata API to see send notifications only for Audited Fields.

3. Allow for "unfollowing" (maybe)

   Users can unfollow a record manually by clicking their Follower record and choosing the Delete action. Alternatively, you could cannibalize the code below to add a method that searches for a Follower with a matching email_address and related_to field. (But then you have to remove the macro and add a JavaScript button to the form, instead. That JavaScript will then use the REST APIs to query the Followers object and display either a [Follow] or an [Unfollow] button--which makes a nice user interface, except that it adds lag time before the form appears.)

Email Template

Template Name: Update Notification

Type: Case Templates (rather than an SLA template)

From Name: Support System

From Email Address: $custom.support_team_email_address

Subject: Case Record Updated

Template Variables:

Case Record Variables:

$cases.case_number, $cases.modified_id.full_name, $cases.description

Current Note Variable (case history): $__current_note__.description

Custom Variable: $custom.support_team_email_address

Here is a sample Update Notification template that uses those variables:

Case Record# $cases.case_number

was updated by $cases.modified_id.full_name

$__current_note__.description

Case Description:

$cases.description

The template HTML looks like this:

<p><b>Case Record#</b> <a href="https://{domain}/networking/servicedesk/index.jsp#_cases/$cases.case_number">$cases.case_number</a>&nbsp;<br />
was updated by $cases.modified_id.full_name</p>
<blockquote>
    $__current_note__.description
</blockquote>

<p><b>Case Description:</b></p>
<blockquote>
    $cases.description
</blockquote>

Code

Tip: Whether or not a field is included in the change-list depends on several aspects of the field--it's name, it's type, and (for extra credit) whether or not it is an Audited Field. That data is defined by the field's "metadata". There are several ways to get that information: To see the kinds of field metadata that is defined https://{yourDomain}/networking/rest/field/{objectName} To see the metadata for a particular field, use https://{yourDomain}/networking/rest/field/{objectName}/{fieldName} To see samples of that data, see REST API:field Resource#Payload Examples

__TBD__

Note: The code above builds the HTML link to the record based on the object and the current application. The logic works correctly, 99.999% of the time. (Applications rarely share objects, even fewer share records in those objects, and it is only links to Task records that could differ.) It is theoretically possible (although highly unlikely) for the same Task record to be shared between two applications. In that scenario, it is also possible for a notification email generated in one application to be sent to someone who doesn't have access to that application. In that highly improbable scenario, the logic could fail. To handle that situation, that appID could be stored in the Follower object. The code that generates the record-link for the message could then be moved inside of the loop that finds Follower records and sends emails. But doing that makes the logic more complicated and harder to comprehend, while at the same time reducing performance. So this code uses the "near-bulletproof" strategy.