Reminder Generation
The reminder functionality provides the ability to set up repeatable notifications on a schedule within the system based on a condition. These reminders run until a stop condition is met and then can optionally run a script. These are focused on a per user and Table basis and numerous can be run on a record at once.
Reminder generator
The reminder generator provides the ability to setup the reminders. Numerous active generators can run against the Table and are currently focused on email notification.
Field | Type | Example | Notes / Description |
|---|---|---|---|
Name | String | Change approvals - Remind twice then reject | This is the name of the reminder generator used to identity a reminder generator. |
Active | Boolean | true | Highlights whether a reminder generator will run or not. |
Table | Table | WorkflowTask | The Table that the reminder will run its conditions off. Note that only tables extended from Work / Workflow task / Interaction entities currently have the appropriate trigger to run the reminder generator. To use it on other entities, simply add an after on create and on update trigger with the following script. ReminderGenerator.processReminders(current); |
Notification | Reference [Outbound notification Table] | Workflow task - Approval request for change | The notification that will run for the record. Note that the Table of the notification should be the same as the reminder generator, otherwise any reference to current in the reminder generator may not work. |
Reminder limit | Integer | 2 | The number of times the reminder will trigger the notification until it will stop running and run the (optional) script to run on reminder limit. |
Initial reminder delay | Duration | 2d | How long to delay before the first reminder is sent. Subsequent reminders are sent according to the duration between reminders |
Duration between reminders | Duration | 1 d 16h | The business duration (within the schedule when populated) of time this Reminder will run. It expects the duration with a number and then period of time (in lowercase) to designate the duration. d: day (24 hours), h: hour, m: minute and s: second. E.g. 4d 3m is the same as 4 days 3 minutes. Note: a 28 hour business duration (say 3.5 business days) will appear as 1d 4h. |
Schedule | Reference [Schedule Table] | Weekdays 9 - 5 | The schedule of the Reminder, which is the source of what hours are considered a business day, public holidays, etc. Note: an empty schedule means the Reminder will run 24x7. |
Timezone | Timezone [Choice - Timezones] | (GMT +10:00) Canberra, Melbourne, Sydney | The timezone of the reminder, which will designate when a schedule will run when chosen. If a schedule has been chosen but this field is left blank, it will look at the user associated to the generated reminder's timezone. |
Users to be reminded | Script | //The approver of the workflow taskanswer = [current.Assignee().getID()]; | This is a server script that has access to the current (current) record to set the associated users that need to be reminded. This must be an array of user ID's, and must be set in the answer variable. Example: answer = [current.Requestor().getID(), current.Assignee().getID()]. It should be noted that if a user is no longer the person who is reminded and there is an active reminder for them, the reminder will become inactive and stop being sent. If this field is left blank, Reminders will still be created for the current record that meets the start condition but without User assigned. The Reminders will be sent to all the recipients (including cc and bcc) defined on the Notification record referenced by the Reminder Generator definition. |
Start condition | Condition builder | Status is Open | The condition that the reminder will start for a record for the users to be reminded. If this is populated along side a start condition script, both have to be true. |
Start condition script | Script | //No advanced script - just needs status as open | The condition that is required to generate a reminder. If the condition is scripted it requires an answer variable to be true or false. Within the script you have access to the current record it is executing on via "current". If this is populated along side a start condition, both have to be true. |
Stop condition | Condition builder | Status Is not Open | The condition that the reminder will start for a record for the users to be reminded. If this is populated along side a stop condition script, both have to be true. |
Stop condition script | Script | //No advanced script - just needs status as not open | The condition that is required to generate a reminder. If the condition is scripted it requires an answer variable to be true or false. Within the script you have access to the current record it is executing on via "current". If this is populated along side a stop condition, both have to be true. |
Script run on reminder limit | Script | //Reject the approval record for the approverWorkflow.reject(current.getID()); | The optional script that runs once the reminder limit has been hit. Within the script you have access to the current record it is executing on via "current". |
How reminders operate
When reminders have been set up for a Table, there is a specific run process in terms of how it runs. This section details what occurs and how the notifications / reminders are generated as a result.
- Once a record has been saved, it will look up all the active reminder generators for that Table.
- In doing so, it will loop through each of the reminder generators and check if it has met the stop condition. If that reminder generator has met the stop condition, it will make all active reminders against the target record inactive and move on to the next generator. If a record meets the stop and start condition, it will only stop it, not start it.
- If the reminder generator does not meet the stop condition, but meets the start condition, it will first determine what people need to have a reminder set up.
- If this list has changed, it will stop any active reminders against users who no longer need to be reminded, start any for those who do and restart the reminder for any users that have an inactive reminder against then and restart the count.
- Once the reminder has been set up and it has met the first scheduled reminder condition, it will up the reminder count as a first step.
- Once done, and the Initial reminder delay has elapsed, it will check if it has met the stop condition If not, it will send the associated notification and the notification subject will be prefixed with the string highlighted in the application property platform.reminder.notification_subject.prefix.
- For subsequent reminder runs, stop condition will be checked against the Reminder’s related current record. If condition is not met, the reminder will be sent out.
- Then it will determine if the reminder limit has been hit for that reminder:
- If it has not, it will schedule the next reminder notification, OR
- If it has, it will make the reminder inactive and stop running.
- Once it has stopped running, it will run the reminder limit script.