==> 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.
Table of Contents
Loan notices events - sent to borrower
Examples of realistic chronological orders of the events:
...
Triggering event | Description | Send options and frequency | Scheduled or immediate?* | Additional process options | Can I use the Multiple loans tokens? |
|---|---|---|---|---|---|
| Check in | Item(s) were checked in | N/A - Always sent at the end of a session and loans are bundled into a single notice for each patron. | 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 - Always sent when event is triggered. | Immediate | N/A - No option Sent once, when the item is renewed in Users. | 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, renewed or the due date is changed to a later date. | 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 - Always sent when event is triggered. | Immediate | N/A - No option Sent once, when the loan due date is changed in Users. | 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 - Always sent when event is triggered. | Immediate | N/A - No option Sent once, when the item is recalled by another patron. | 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 or an aged to lost fee/fine is charged. | Scheduled | N/A - No option | No |
...
| Info | ||
|---|---|---|
| ||
"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. Only one scheduled notice is stored at a time; once that notice has been sent out, the "nextRunTime" field is updated with the next scheduled send date/time. The scheduled notices processor can process up to 100 items every time it runs. 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. |
Request notices events - sent to requester
Examples of realistic chronological orders of the events:
...
Triggering event | Description | Send options and frequency | Scheduled or immediate?* | Additional 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 - Always sent when event is triggered. | Immediate | N/A - No option. Sent once, when the item is checked in and now ready to be picked up. | No |
Page request (Confirmation notice) | Page request placed | N/A - Always sent when event is triggered. | Immediate | N/A - No option. Sent once, when the page request is saved. | No |
Hold request (Confirmation notice) | Hold request placed | N/A - Always sent when event is triggered. | Immediate | N/A - No option. Sent once, when the hold request is saved. | No |
Recall request (Confirmation notice) | Recall request placed | N/A - Always sent when event is triggered. | Immediate | N/A - No option. Sent once, when the recall request is saved. | No |
Cancel request | Request was cancelled | N/A - Always sent when event is triggered. | Immediate | N/A - No option. Sent once, when the request is cancelled. | 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. | 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. | Scheduled | N/A - No option. | No |
Fee/fine notices (sent to borrower)
Examples of realistic chronological orders of the events:
...