The Alert system

An Alert system is provided to advise staff members about errors detected during the processing of the information they have just entered in RefTracker. At present the Alert system is just used to advise staff when RefTracker has been notified by an email server that an email that should have been sent by the function that was just performed, could not be delivered (note that only some email systems provide immediate feedback like this – most provide non-delivery notices that RefTracker handles via email importing associated with the Service email address).

However this Alert system is a powerful function and will be used for immediate notification of more things in the future.

When an Alert occurs in relation to any question allocated to you, or in relation to the question number that you are currently viewing (whether it is allocated to you or not), information about the Alert will appear at the top of the next question answering main window page that you visit, in a format similar to that shown in the screen print below. Alerts do not appear in subwindows like DeskStats and Manage attachments, or some main window pages where that information is not useful (like the Reporting pages, or the page that allows error information to be reported.

The Alert display will continue to display at the top of each relevant screen that you visit, until you address it by using the “Resend” function, or clicking on “Resolved” in the resolution drop down in the top right hand corner.  Alternatively you can choose a “Reminder” option in that drop down list to have the message temporarily stop displaying for the selected time period.

This means that the information can stay in view while you investigate the problem, or you can set a reminder to deal with it later. You can use all RefTracker functions as usual while an Alert display is showing, so, apart from the screen space it uses, there is no reason why you can’t just let the Alert continue to display until there is an appropriate time to address the issue it raises.

The Alert can be “Resolved” by any staff member that is being shown it, but the person who selects “Resolved” in the [Select resolution] drop down list is recorded in the History, so they need to responsibly address the issues that it raises, before they mark it as “Resolved”.

Addressing the issue means doing whatever is required to cope with the fact that the expected process did not occur – for example, in the instance of an “Email transaction failed” Alert, the email address shown at the top of the message could be an incorrect email address.
If it is a simple misspelling, you may recognise it immediately and can go to the Change screen and correct it. Once the email address is corrected you can resend the email by redoing the process that you used to create the email that did not send (for example by reopening the question and closing it again to re-send the response – or by sending an Inform client message, if it was a confirmation of receipt email that was not sent).

If it is a message that indicates that the receiving email server was unavailable to send the email, you will need to Resend the email when the email server is available again.  You can resend it by using the provided Resend button.
When you click this Resend button in the email alert message, it sends the recreated email, the alert is removed from the screen and it is marked as acknowledged in the History, a popup message confirms that an email has been sent, and a note about the Resend is placed in the history confirming that the email was sent.
Please note that this process recreates the email from the information in the history so, if you need to change anything about the email, you need to recreate it (as described above), not Resend it.

Sometimes there is no point in resending the email, for example if it was a Reallocation message to a staff member, and someone has already started work on the question in the mean time! When this happens, the Alert should just be marked as “Resolved” even though nothing was done to resolve it.

For easy access to the question for which this Alert occurred, the question number in the Alert box is hyperlinked to the Details tab of the Summary screen, but you can of course just enter the question number in the Question number box in the Question action header bar and click on the answering function that you want to use. As other actions may have occurred on the question since the Alert was first created, it is a good idea to use the Question number link in the Alert message to view the information in the Details and History tabs of the Summary screen before trying to address the issue (for example, the client may have noticed the email address was incorrect, and have corrected it themselves).

The History tab of the Summary screen has an entry that shows when this error occurred in the sequence of actions that have occurred in relation to this question. In the screen print below you can see that the Alert is clearly indicated with a large yellow asterisk (*).

When it is “Resolved” (or you uses the Resend button), the status of the alert is changed to “Acknowledged” in the History entry. In this case (see History tab of the Summary screen print below) the entry in the History tab of the Summary screen shows the sequence of events that records that the answer email was not sent, and who it was resolved by. When the staff member uses the Resend button, or corrects the email address and resends it, those corrective actions will also show in the History tab of the Summary screen as separate entries. 

Testing the Alert process

You can deliberately generate one of these Alerts by entering ‘White rabbit’ in the Client name and ‘Cheshire cat’ in the  Places already looked (Question) field.
If both of these are present the email function will use alice.wonderland.com as the mail server which will cause an Alert to be generated.