==> Understand what events are available to trigger notices, and how they can be configured. <==
Patron notice policies determine which patron notice templates are sent out before, during, or after certain triggering events. Read on to lean how each event can be configured.
Loan notices events - sent to borrower
Examples of realistic chronological orders of the events:
| Check out | → | (Before) Loan due date/time | → | (After) Loan due date/time | → | Item renewed | → | (Manual) Loan due date change | → | Item aged to lost | → | Check in |
| Check out | → | Item recalled |
How each event is configurable (in the order they are listed in the notice policy):
Triggering event | Description | Send options and frequency | Scheduled or immediate?* | Process options | Can I use the Multiple loans tokens? |
|---|---|---|---|---|---|
| Check in | Item(s) were checked in | N/A - Upon/at is inferred | Immediate | N/A - No option Sent once, when the check in session is ended. | Yes Always sent with multiples by patron by session and template selected must be configured for multiple loans/items: {{#loans}}{{/loans}}. |
Check out | Item(s) were checked out | N/A - Upon/at is inferred | Immediate | N/A - No option Sent once, when the check out session is ended. | Yes Always sent with multiples by patron by session and template selected must be configured for multiple loans/items: {{#loans}}{{/loans}}. |
Item renewed | Items were renewed by borrower. In the circulation log, the due date/time is documented as changed by system. | N/A - Upon/at is inferred | Immediate | N/A - No option System is scanned every 5 minutes for triggering events and sent when an item renewed is detected. | No |
Loan due date/time (Used for reminder and overdue notices) | Loan’s due date/time (This event is a pre-determined time-based event, i.e. you know the time when the item is due to be checked in) |
When Before + recurring** frequency, then notices will stop being sent at the due date/time. When After + recurring** frequency, then notices will stop being sent when the item is checked in, declared lost, aged to lost or claimed returned. | Scheduled | Option 1 for days, weeks, months (i.e. long-term loans): Send overnight with multiple loans/items by patron.
Option 2 for minutes, hours (i.e. short-term loans): Send throughout the day without multiple loans/items.
| |
Loan due date change | Due date/time was changed manually in the Users app. | N/A - Upon/at is inferred | Immediate | N/A - No option System is scanned every 5 minutes for triggering events and sent when loan due date/time change is detected. | No |
Item recalled | Item was recalled by another patron. In the circulation log, the due date/time is documented as changed by system. | N/A - Upon/at is inferred | Immediate | N/A - No option System is scanned every 5 minutes for triggering events and sent when an item recalled is detected. | No |
Item aged to lost | Item state was changed to “aged to lost” as per the lost item fee policy. |
When After and recurring** frequency, then notices will stop being sent when the item is checked in, declared lost or claimed returned. | Scheduled | N/A - No option System is scanned every 5 minutes for triggering events and sent when an item status changes to aged to lost. | No |
Request notices events - sent to requester
Examples of realistic chronological orders of the events:
| Page request | → | Check out | or | Cancel request (available for Page + Hold + Recall) |
| Hold request | → | Check in | → | Awaiting pickup | or | Request expiration (available for Page + Hold + Recall) |
| Check out | → | Recall request | → | Check in | → | Awaiting pickup | → | (Before) Hold shelf expiration | → | Hold shelf expiration (available for Hold + Recall) |
How each event is configurable (in the order they are listed in the notice policy):
Triggering event | Description | Send options and frequency | Scheduled or immediate?* | Process options | Can I use the Multiple loans tokens? |
|---|---|---|---|---|---|
Awaiting pickup | Recalled item was checked in at the requested service point and now it’s available and awaiting pickup | N/A - Upon/at is inferred | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when an item awaiting pickup is detected. | No |
Page request (Confirmation notice) | Page request placed | N/A - Upon/at is inferred | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when a page request is detected. | No |
Hold request (Confirmation notice) | Hold request placed | N/A - Upon/at is inferred | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when a hold request is detected. | No |
Recall request (Confirmation notice) | Recall request placed | N/A - Upon/at is inferred | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when a recall request is detected. | No |
Cancel request | Request was cancelled | N/A - Upon/at is inferred | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when a request cancellation is detected. | No |
Hold shelf expiration | Hold shelf expiration date/time (This event is a pre-determined time-based event, i.e. you know the time when the item is due to be checked in) |
When Before + recurring** frequency, then notices will stop being sent when expiration is reached. | Scheduled | N/A - No option. System is scanned every 5 minutes for triggering events and sent when hold shelf expiration is detected. (for Upon/at) | No |
Request expiration | Request expiration date/time (This event is a pre-determined time-based event, i.e. you know the time when the item is due to be checked in) |
When Before + recurring** frequency, then notices will stop being sent when expiration is reached. | Yes | N/A - No option. System is scanned every 5 minutes for triggering events and sent when request is detected. (for Upon/at) | No |
Scheduled or immediate?*
"Scheduled", in this context, means “stored in the database in order to be sent later”. All notices with time-based triggering events, including due date/time, hold shelf expiration and request expiration, are scheduled, because we know when the notice will be sent.
The oposite to "scheduled" is "immediate", e.g. when the notice is sent at the end of a check-out session, because we _don't know_ when the notice will be sent, i.e. we cannot plan ahead exactly when the check-out session will end.
"Scheduled" is not opposite to "real-time", language used in previous releases that caused confusion! Rather "sendInRealTime" is
"sendInRealTime" : true – This refers to the option "Send throughout the day without multiple loans/items." for the tigger "Loan due date/time". I.e. the courtesy email is sent when the scheduled time is reach, NOT at a later time when being bundled with other reminders.
"sendInRealTime" : false – This refers to the option "Send overnight with multiple loans/items by patron." for the tirgger ""Loan due date/time". I.e. the courtesy email is NOT send when the scheduled timed is reached, but at a later time when being bundled with other reminders.
A scheduled notice references a template by ID only. The template is fetched just before sending the notice. As a result, any changes made to the referenced template from the time it was first scheduled and the time it is sent will be reflected in the notice sent to the patron.
Fee/fine notices (sent to borrower)
Examples of realistic chronological orders of the events:
| Check out | → | (After) Loan due date/time | → | Check in | → | Overdue fine, returned |
| Check out | → | (After) Loan due date/time | → | Item renewed | → | Overdue fine, renewed |
| Check out | → | (After) Loan due date/time | → | Item aged to lost | → | Lost item fee(s), charged | → | Check in | → | Lost item returned - fee(s) adjusted |
How each event is configurable (in the order they are listed in the notice policy):
Triggering event | Description | Send options and frequency | Scheduled or immediate?* | Process options | Can I use the Multiple loans tokens? |
|---|---|---|---|---|---|
Overdue fine, returned | Overdue fine charged to patron when the overdue item is checked in. |
When After + recurring** frequency, then notices will stop being sent when the fee/fine is closed. | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when an item awaiting pickup is detected. | No |
Overdue fine, renewed | Overdue fine charged to patron when the overdue item is renewed. |
When After + recurring** frequency, then notices will stop being sent when the fee/fine is closed. | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when an item awaiting pickup is detected. | No |
Lost item fee(s), charged | Lost item fee charged when item ages to lost, then the fee is charged to patron (the schedule is set in the lost item fee policy). |
When After + recurring** frequency, then notices will stop being sent when the fee/fine is closed. | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when an item awaiting pickup is detected. | No |
Lost item returned - fee(s) adjusted | Lost item fee adjustment, such as remove processing fee, when the aged to lost item is checked in (if applicable, as configured in the lost item fee policy). | N/A - Upon/at is inferred | Immediate | N/A - No option. System is scanned every 5 minutes for triggering events and sent when an item awaiting pickup is detected. | No |
Recurring**
If recurring is selected, then when the notices stop being sent is not configurable. The tables above inform you, when the notices will stop being sent for recurring notices.