wMobile Notification Services
wMobile Notification Services is a framework that enables the system to react to the occurrence of particular events in different components by executing user related notification actions.
Basically, it will allow the users of the system to be notified by Email, SMS or other means when an event occurs as consequence of interaction flow or as consequence of time flow.
The notification process is rule based and it can be customized as needed from the wMobile Manager Console. For each type of event defined by the system (PendingActivityAdded, ActivityCompleted, AlarmExpired, etc.), there are rules that determine what actions will be taken.
The Notification Services will allow wMobile users to receive activity related email notifications generated when Notify via Email or RSVP checkboxes are checked during activity creation or update flow. Also, support for alarm notifications is provided, if enabled from Manager Console.
In this section we’ll show how activity notifications work for both single activities and activity series. Initially, we’ll focus on two types of notifications for each case:
- Notify via Email – occurs when the Notify via Email check box is checked when scheduling or updating an activity. In this case the assignee user(s) will be notified when other users schedule or modify the activity he/she has been assigned for.
- RSVP notifications – occur when Auto-generate RSVP check box is checked and a user will complete or delete the specified activity. In this case, the user that created the activity will be notified when somebody else completes or deletes the activity.
Single Activity Notifications
In this section we’ll see how email notifications are sent when users are creating, changing, deleting or completing individual activities.
Notify via Email
We’ll see how notifications are sent to the assigned user, if he/she is different than the creator, when an activity is scheduled. The assigned user will receive also a change notification if somebody else is changing the activity.
Let’s see a concrete scenario for each situation mentioned above.
Notify via email – Schedule Activity
Scheduling User: MASTER (firstname.lastname@example.org)
Assigned User: USER1 (email@example.com)
After we schedule the activity, USER1 (firstname.lastname@example.org) will receive the following email:
So, USER1 will be notified that an activity has been scheduled and assigned to him.
Notify via email – Change Activity
Modifying User: MASTER
Assigned User: USER1 (email@example.com)
After the activity, is saved, USER1 (firstname.lastname@example.org) will receive the email below:
So, USER1 will be notified that the activity assigned to him has been changed.
With RSVP the creator will be notified about activity completion and deletion, if those actions have been performed by another user.
RSVP – Complete Activity
Scheduling User: USER1 (email@example.com )
Completing User: USER2 (firstname.lastname@example.org )
USER1 creates an activity and assign it to USER2. Next, when USER 2 completes the activity, USER1 will be notified about that action.
So, USER1 has been notified that USER2 has completed the activity.
Let’s consider now the case when the activity is deleted.
RSVP – Complete Activity
Scheduling User: USER1
Deletion User: USER2
The first part of this scenario is similar to the activity completion scenario above. USER1 schedules an activity for USER2.
Next, USER2 will delete the activity and USER1 will be notified about that action by email as you can see below:
Next, we’ll see how notifications work for activity series.
Activity Series Notification
In this section we’ll see how email notifications are sent when users are creating, changing, or deleting activity series. There are two types of series we’ll use in the scenarios below:
- Multiple activities series – that is created when an activity is scheduled to multiple users/contacts.
- Recurring activity series – that is created when recurring activities are created.
Notify via Email
Notify via Email – Schedule new multiple activities series
In this scenario we’ll schedule an appointment to a filter and will set MASTER user as primary user and another two users, USER1 and USER2 as additional users as you can see in the figures below:
After activity is scheduled, both USER1 and USER2 will receive a notification about the newly created activity series. MASTER user will not receive such an email because he is the creator.
USER1 receives an email that contains information about activity series:
USER2 also receives an email that contains information about the activity series:
Notify via Email – Change multiple activities series
In this scenario we’ll consider that we have an activity series created like above, and the creator, MASTER user in this case, changes the notes for all activities in the series. The other users, respectively USER1 and USER2, we’ll receive an email like below after the series has been changed.
Notify via Email – Schedule/Change recurring activity series
When scheduling a recurring activity series, the same rules as above apply. The only difference is the email content received by the assigned user as you can see below:
For the moment, completing an activity series is not yet supported. We’ll update this article once we’ve added that features. We’ll show below how email notifications are sent when deleting a multiple activity series and a recurring activity series.
RSVP – Delete multiple activity series
RSVP – Delete recurring activity series
In this case the message is similar to the ones related to activity series creation or change.
By default, alarm notifications are not enabled in wMobile. If you want to use them, you need to enable them from Manager Console and we’ll show you how to that in the next sections related to notification services configuration.
Once this behavior is enabled, wMobile will send email notification to the assigned activity user when the alarm expires. Let’s assume that USER1 has an activity scheduled at 5:00 PM with an alarm that is set 10 minutes before.
wMobile uses background tasks called Event Monitors to trigger time flow related events and send notifications to the appropriate users. In this case, the task is called Alarm Monitor.
The Alarm Monitor checks each minute for expired alarms and notifies the assigned users.
Notification Services Configuration
Notification Services behavior can be setup or changed from Manager Console. We can enable/disable notification rules or event monitors, we can change the SMTP server settings and manage failed notifications. You can access Notification Services configuration from the manager console as shown below:
Email Notification Settings
The first thing that you will want to set before using Email Notifications is the configuration for the SMTP server that will be used to send email notifications asynchronously.
Once you have entered Notification Services configuration, click the Email Settings node in the left tree and enter your SMTP server settings. Then click the Test Settings link to the right and if everything tests ok, click Save.
Note: All email notifications are sent asynchronously via Email Fetcher service. wMobile users will not have to wait for emails to be sent, this process being transparent for them.
wMobile comes with a set of built-in notification rules that define the actions that will be executed under certain condition, when a specific event is fired. Each notification rule has a description that explains its behavior.
As we mentioned earlier, wMobile uses some background tasks to fire time flow related events like alarm expiration. These tasks are called Event Monitors and they are running inside wEmailFetcher.
Currently wMobile deploys an Alarm Monitor that is used to fire alarm expiration events. This monitor is not enabled by default when you install wMobile. If you want alarm notifications in your system, you’ll need to open Notification Services configuration, select Alarm Expired Monitor in the event monitor list and enable it. At the end click the Save link to the right, and click OK when prompted to restart Email Fetcher. The fetcher restart is mandatory in order for Alarm Monitor to run.
Sometimes, the system will not be able to send email notifications. Maybe the email server is down or is not accessible or the server settings have been changed, but in the end your notifications will not be sent.
By default, the system will try to send a notification for a specified number of times. Once that number is reached and the notification cannot be sent, it will be moved into a list of Failed Notifications.
This list is accessible from Manager Console and the notifications can be further managed as follow:
- They can be reposted in the notification queue for retry
- They can be removed from failed notification list