When Date is Reached Automatically Send Email Notification to Requestor

[eric987dc]

We currently have a solution which uses the Service Catalog - Items. After a requestor requests this item and it goes through the entire approval process. At the end, it will have a start date. Whatever that start date may be, we are trying to somehow record that date and set a timer so that 2.5 years from that start date, an email will be sent to that same requestor asking for their review. This same process on will repeat again 5.5 years and 8.5 years if the end date is long enough. We will need to condition this process to repeat only the number of times required by the length of the request. 

We did not want to put a wait for condition in the workflow because we wanted that request to be closed/complete.

We also need the ability to ask a few questions and obtain metrics on the number of reviews sent/replied/and their answers. 

What/How is the best method of completing this? 

Thanks for any help!

[Giles Lewis]

Regarding notification recipient:

When you call gs.eventQueue(), the 2nd argument is a glide record. In my example above I should have written gs.eventQueue('name_of_event', gr, parm1, parm2). Parm1 and parm2 are optional.

When you add an event to the Event Registry, you give it a name and the specify the type of table.

In order to define a notification on an event you must use "Advanced view". Once you select the event you can reference fields from the record (as specified in the registry) under "Who will receive" and "What it will contain". For example, suppose your custom table contains a field named "Request Item". Then for "User/groups in fields" you should be able to dot-walk from Request Item -> Request -> Requested for.

Sometimes people use the parm1 and parm2 fields to hold the sys_id of the recipient. This allows the recipient to be determined by the javascript code that creates the event instead of being defined in the notification. Under "Who will receive" there are check boxes for "Event parm 1 contains recipient" and "Event parm 2 contains recipient". However, I normally prefer using "User/groups in fields" as it is clearer to anyone reviewing the Notification definition.

Events are cool because they make it easy to test your notifications. Suppose you have a record whose sys_id is known, and you want to generate a test notification for that record.  Use the following 3 line background script:

var gr = new GlideRecord('my_table_name');
gr.get(sys_id);
gs.eventQueue('my_event_name', gr);

These 3 lines will create an event, which will in turn trigger the notification.

Regarding reporting:

Records in the sysevent table do hang around very long. They are typically auto-deleted after a few days. They can be useful for an administrator to troubleshoot (was the event generated last night?), but should not be used for reporting.

Make sure that any data which is required for reporting has been saved in a custom table or in a task table such as sc_req_item.