SWIMS Network and SWIMS System
You are here: SWIMS > System General > Alerting

SWIMS Alerting

 

  1. What is alerting on SWIMS and what notices are available?
  2. How can alerts be suspended and how does this work?
  3. What may be the cause if a user has apparently not received an emailed notice from SWIMS which they should have?
  4. How can I monitor for alerts which haven’t been delivered?
  5. How can I resend an email alert which failed first time?

 

What is alerting on SWIMS and what notices are available?

Alerting is a means by which notices are sent to end users and suppliers by email.  These notices are either sent manually by the librarian, or are generated automatically by OLIB and sent out either immediately or in the early morning as part of OLIB’s ‘daystart’ process depending on the type of alert.   In order for a user to receive notices, their email address must be recorded in the email address field on the user record.  A record of alerts received are recorded on the notice history tab in the user’s record, and also in the notice itself.

It is possible to stop notices to a particular user by setting ‘Suspend Email’ on the notice history tab to Yes.

Any particular alert can be set up so that records of notices sent are purged from the system after a specific time period or a specific number have been sent.

How to set them up:

If you would like any of these alerts set up for your location, please contact your system administrator.  Only system administrators can create, amend or delete notices but all librarians can send them (where this is appropriate, i.e. in the case of manually generated notices).  It can be helpful to test notices on library staff before making available to end users.

Notices available:

Emailed overdues – generated in daystart

Broadcast emails – sent manually by the librarian – use these as a way of emailing groups of users, e.g. to notify of a library closure or of imminently expiring membership.  Users can be selected on the basis of location or user category or both, or as individual users.  If the Users field is populated, the Location and User Category field are ignored whether populated or blank.  If the Users field is blank, but both the Location and User Category field are populated, the users have to match both parameters in order to receive the email.

If a notice were to be sent by mistake with none of the User Category, Location or Users field populated, it would go to all users on the system.  For this reason it is essential to leave broadcast emails with at least one user selected in User field.  SWIMS Network mandatory policy.

In order to receive broadcast emails, users must have the ‘Receive broadcast notices’ flag in their user record (in the Notice History sheet) set to yes.  All users have this set to Yes by default but this can be changed to No if required.  To identify users with this set to no, refine on ‘Opt in’ = No, and also refine on location as desired.

Recall notices – sent manually by the librarian

Loan reminders – sent a few days before the due date – generated in daystart

Loan reminders before expiry – sent a few days before user expiry – generated in daystart.

Reservation notices – 6 are available but only 4 of these are likely to be useful – generated in daystart

  • Reservation held – sent to user
  • Held Reservation Soon To Be Cancelled – sent to user 3 days before expiry (determined by ‘Hold Period’ in location record) (NB this was 2 days until the application of Service Pack 2 on 7 March 2011)
  • Held Reservation To Be Cancelled – sent to member of staff/circ desk
  • Reservation cancellation – sent to user

Circulation transaction alerts – these are sent automatically by OLIB to the end user as soon as a circulation transaction has been carried out, to confirm it has taken place.  They can be set up for different transactions including issue, return, renewal and unseen renewal.  (Introduced with OLIB 8.2)

Serials claims – generated in daystart

Acquisitions claims – generated in daystart

Back to Top


How can alerts be suspended and how does this work?

In tests, suspending simply allows the emails to back up until the suspension is lifted at which point they are sent out by the system.

Suspending for a user
The Suspend All Emails flag is included at the top of the user record Notice History sheet to indicate whether the system should suspend all email alerts to that user.
In addition, a set of fields is included underneath the Suspend All Emails flag to control whether and when email overdues should be suspended to a user.
The Suspend Odues On field determines when the suspension should begin.
The Suspend Reason field is used to record why overdues are being suspended for this user.
The Odues Suspended? flag determines whether overdues have been suspended for this user.
The Resume Odues On field is used to indicate when to resume sending overdues by email to this user.

This facility should be used as follows:

Set the Suspend Odues On field to the date on which email overdues should be suspended to this user. Optionally, add a reason in the Suspend Reason field. An overnight process identifies all users who should have email overdues suspended that day, and it sets the Odues Suspended? flag to Yes for those users. It also clears out the Suspend Odues On field. Whilst the Odues Suspended? flag is set to Yes, the user will not receive any email overdues.

Alternatively, manually suspend email overdues for a user simply by setting Odues Suspended? to Yes.

Another overnight process identifies all users who should have email overdues resumed that day. For these users, the Odues Suspended? flag is set back to No, and the Resume Odues On field is cleared.

Suspending for all users in a User Category

There are equivalent Odues Suspended fields on the user category screen. If a user category’s Odues Suspended field is set to Yes, no users with that user category will receive email overdues.

Suspending for a copy

This is also possible but the required fields have not been made available on SWIMS.

Back to Top


What may be the cause if a user has apparently not received an emailed notice from SWIMS which they should have?

(Emailed notice delivery can be checked in the Notice History tab of the user record and in the Notice Alert History tab of the alert record.)

  • The user doesn’t have an email address in the Email Address field of the user record
  • The user does have an email address in the Email Address field but it is for an account no longer used, or it has a typo
  • The user has two or more email addresses in the Email Address field but they aren’t separated by a semi-colon
  • Problems with the user’s email account or trust email service, for example the email has been rejected because the user’s inbox is full, or the trust/organisation is blocking the email, or the email has in fact been delivered to the user’s account but has gone into junk/spam
  • The user has a suspension for either all notices or just emailed overdues (see the Notice History tab of the User Record)
  • It is a broadcast email and the user has the Opt In for broadcast emails set to No (see the Notice History tab of the user record – the default for all users is Yes but can be changed manually to No)
  • The notice has actually been delivered but has since been purged from SWIMS (see the Notice History of the notice for purge details)
  • The OCLC email server has failed and OCLC need to resend all notices
  • ‘Daystart’ has failed and OCLC need to rerun this so that the notices are emailed
  • There is another technical fault which needs to be followed up with OCLC

If you suspect one of the last 3 on this list may be the cause, please contact your SWIMS System Administrator.

Back to Top


How can I monitor for alerts which haven’t been delivered?

The new From email address DoNoReply@oclc.org implemented for all notices on 28th April 2016 is not monitored for bounces, e.g. in the case of mailbox full or email address no longer in use.

With regards to email addresses which aren’t formatted correctly, e.g. with spaces or lacking the @ symbol, there is no report to identify these.  The SWIMS system administrators check and correct these periodically (see note below about OLIB then sending out alerts after email addresses have been corrected), and there is a possibility in future that the field will be ‘validated’ meaning that only correctly formatted email addresses can be entered. 
Library staff can also check for cases in which SWIMS has been unable to deliver an alert because the email address syntax is wrong.  To do this for your location:

  • Launch a search on Alerting > Notices
  • Carry out a search for your Notices – if in doubt carry out a wildcard % search
  • For each one, display in full then click the Notice Alert History tab.  Look at the ‘Not Sent Alerts’ box and if there have been any problems these will be recorded against the entry for that Notice to the right of the recipient’s name in the Notes column. 
  • You can then search for the user and correct the email address. Launch a user search and change to Users by E-mail ID.  Enter a specific email address or use a wildcard search eg john% retrieves all user records containing email addresses which start with john; %.bournemouth.ac.uk retrieves all user records with email addresses in the Bournemouth University domain.

The email address can then be corrected in the user record.  If the exact email address is unknown, a trap can be placed on the user record to ascertain the correct one from the user in question.

If you add an email address or correct one from an incorrect format to a correct format in a user record after an item has gone overdue, and whilst it is in the middle of an overdue sequence, only the remaining emails in an overdue sequence will be automatically sent.  This will start in the next overnight ‘daystart’ process.  The backlog will not be sent out and emails won’t be sent if the item has since been returned or renewed.

If already sent overdue notices need sending again the resend method will need to be used – see below.

An explanation of the data displayed on the Notice Alert History tab on the alert record

  • The Ready To Send Alerts field displays alerts that are ready to send, including the date on which they are due to be sent
  • The Not Sent Alerts field displays the alerts that were not sent, together with an indication of the reason why they were not sent (Item renewed before the alert could be sent, Item returned before the alert could be sent, etc).
  • The Sent Alerts field displays alerts that have actually been sent.
  • The remaining boxes display the same data in different formats.

Back to top


How can I resend an email alert which failed first time?

It is possible to resend alert emails, including overdues, if they failed the first time.  If necessary, first correct the email address in the user’s record.

  1. Launch a search on Alerting > Notices
  2. Carry out a search for your Notices – if in doubt carry out a wildcard % search
  3. In the Notice Alert History tab, scroll down to the Email History box.
  4. Tick the notice, click Other Actions, then select an option

The options are:
Resend Email to All – sends the email again to all the recipients (even though you have only ticked one user)
Select recipients for resend – lists the original recipients for you to select one or more to resend the email to (not currently working and on OCLC’s list for fixing – however it is possible for a SWIMS system administrator to do this for you by carrying out a search on System Administration > Email History, refining on Sending Status of FAIL, and Date/Time of the date sent)
Send from Current User – resends the email to the original recipients, this time setting the From address to the currently logged in user’s email address
Send to Current User – sends the email to the currently logged in user’s email address

You can resend emails to a different email address from the original:

  1. In the Email History box, and click it to display the full details.
  2. Modify Record and in the Resend email to box enter the new email address for the alert to be sent.  Save and Close.
  3. Back in the Email History box, tick the alert and in the Actions box, click Resend from current user.

OLIB creates a new email history record which is marked as being a resend of the original.

Back to top