Notification type | When to use? | Advantages | Limitations |
|---|---|---|---|
Notification | Notify about all the items that satisfy the conditions of the filter at every scheduler run. Example: Service Desk manager wants to be notified about all the reservations and their current statuses. | Simple way to send notifications based on a generic filter. | - Search is run on the entire business object every time. - Time related macros cannot be used in filters. - User cannot send notifications based on events within a scheduled time. |
Notify only once | Notify about a condition only once and never again. Example: User needs to be notified on a particular contract when it reaches ‘X’ days before its end date. | Runs only once and avoids unwanted email traffic. | - This is not implemented at the order level but at the notification definition level. Consequently, if an exception occurs, the successful notifications are also sent again. - When the scheduler engine is disrupted during its run or fails to work, there is no queue maintained for the notifications that were to be sent at that point of time. |
Event based notification | Notify when an event or action has occurred. Example: User wants to send emails with respect to a status change or field change in the application depending upon the solution extension created. Example: Service Desk manager wants to be notified about all reservations which are administratively completed. The solution extension is triggered during the status change of the BO. | - No scan is required on the entire BO but only on those instances which are present as Tasks. - Works also when the system is down for a while. Example: contracts that need to be notified 10 days before the completion. Even if the system is not running at that moment, the task based notifications will be sent. - Any disruption of the scheduler engine does not lose the tasks that still have to be performed. | - |