User notifications

19.08.2015

Notifications are messages sent to users based on actions or events that occur in a system. In this text we would like to focus on a generic solution, i.e. system that by a simple configuration enables to create new notifications and further modify them. (Thus we do not speak about the situation when developers hard-code an email that is sent to specified recipients if something happens in the application they created.)
How should such a generic system look like? Let`s take a look on it in the following picture.

On the left we can see examples of various objects from which the notification can be called:

  • Class rule – e.g. after saving a new or changing already existing record
  • Workflow – e.g. after approval or rejection of a user request
  • Job – e.g. after executing certain job steps
  • Export – e.g. information about regular data publishing
  • Import – e.g. information to administrator about successful or unsuccessful data import from another system
  • Script – possibility to utilize system of notifications also from script
  • …and more

It is possible to respond to each event by more notifications. Particular notifications can then be conditioned e.g. by a value in certain column, so a particular notification is sent e.g. at the change of the Request record, only if the column Status has value „Returned to requestor“.


The recipients can be defined by a distribution group whose members can be both internal users of the system but also external recipients. Recipents of the notification can be also defined as users in certain column. This enables dynamic recipient selection in comparison with a static distribution group, that has a fixed list of its members.

 

It is also necessary to ensure correct localization of the notification text. Preferred language for notifications is defined in the user profile.

 

Notifications may use various channels (emails, SMS…). A simple text or html can be used for emails, same like email templates. Templates help to ensure a unified appearance of certain notifications.

 

Sent emails need to be recorded in a log. They represent a proof of sending the notifications.

 

At the same time it is necessary to avoid enormous database growth. Therefore the system enables definition of an automated clearance of this log with standard interface for Log maintenance.

Within notifications there can be used properties of the record from which the notification was called. Therefore it can be dynamically adopted according to the current data.


Everything described above is available in ObjectGears on click and can be fully utilized by a user without any knowledge of programming. If users create data structures according to their needs and assign necessary access rights they are neither in case of notifications dependent on developers resources. This represents big potential in case of future need for changes in the application both in terms of flexibility, ease and speed of changes and in terms of not consuming developer resources (approval process, budget…).


No matter if you use or want to use ObjectGears or another system, you should always require on that system in the are of notification above stated features.


In ObjectGears we try also in case of notifications to offer something more and to develop the system all the time. One of examples are notification groups.


Imagine a situation when you need to send various notifications to various groups of people responding on a single event  - e.g. a text with one link to one group of people and text with another link to another group of people. Of course, you can prepare several various notifications for various groups of people. Problem is if somebody is member of more groups. In such a case this person receives several notifications. Such a solution is in fact often used because otherwise you would have to code complex logic which is needlessly expensive and inflexible. If the users receive several duplicate notifications once a week, they will probably  ignore it. However, if duplicate messages are sent more frequently, they will be discontended which they will show.


In ObjectGears we wanted to solve this known situation and our response are just notification groups. How to use them? Set the same Notification group to all the notifications responding to a single event where duplicate message shall be avoided. Order of the notifications shall then be set from the most specific (sent as the first one) to the most common (sent as the last one). If certain notification belonging to a group is sent to a user, then other notifications from the same group are not sent to the user any more.