==> Understand what events are available to trigger notices, and how they can be configured. <==
Valid up to the Orchid release. New functions/options released in Poppy are marked in Poppy-red.

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?*	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)	Upon/at Before After 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, 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. These are processed overnight (11:59 PM) Template must contain reference to multiple loans: {{#loans}} {{/loans}} 100 notice/loan records are processed every 2 minutes. Option 2 for minutes, hours (i.e. short-term loans): Send throughout the day without multiple loans/items. These are processed every 5 minutes throughout the day. Template *must not* contain reference to multiple loans: ~~{{#loans}} {{/loans}}~~
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.	Upon/at After When After and recurring frequency**, then notices will stop being sent when the item is checked in, declared lost, claimed returned or an aged to lost fee/fine is charged.	Scheduled	N/A - No option	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. 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 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" determines whether a notice gets batched and sent overnight:

"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.
- Example for "sendInRealTime" : false: An item is checked out at 2 pm on a 3-day loan, with an overdue notice set to run every 1 day after it goes overdue So the overdue notice nextRunTime would be 2 PM + 3 days, but wouldn't actually run until 23:59 of +3 days. And the batch set of notices that runs on 23:59 would pick up ALL of the notices scheduled to run on that day.

The scheduled notices processor ("handler") runs every so often, to check whether there are any scheduled notices to send. The default setting in the module descriptor are as follows:
_ For Category = Loan + "sendInRealTime" : true, the scan is every 5 minutes.
_ For Category = Loan + "sendInRealTime" : false, the scan is every 2 minutes.
_ For Categroy = Request, the scan is every 2 minutes.
_ For Category = Fee/fines, the scan is every 2 minutes.

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:

Page request

→

Check out

Cancel request (available for Page + Hold + Recall)

Hold request

→

Check in

→

Awaiting pickup

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?*	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 hold shelf will expire)	Upon/at Before 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 request will expire)	Upon/at Before 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:

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?*	Additional process options	Can I use the Multiple loans tokens?
Overdue fine, returned	Overdue fine charged to patron when the overdue item is checked in.	Upon/at After When After + recurring frequency**, then notices will stop being sent when the fee/fine is closed.	Scheduled	N/A - No option.	Change with Poppy: Yes Always sent with multiples by patron by session and template selected must be configured for multiple loans/items: {{#feeCharges}}{{/lfeeCharges}}.
Overdue fine, renewed	Overdue fine charged to patron when the overdue item is renewed.	Upon/at After When After + recurring frequency**, then notices will stop being sent when the fee/fine is closed.	Scheduled	N/A - No option.	Change with Poppy: Yes Always sent with multiples by patron by renewal action and template selected must be configured for multiple loans/items: {{#feeCharges}}{{/lfeeCharges}}.
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). Addition with Poppy: When the actual cost is charged is charged to the patron (both for aged to lost, and for declared lost).	Upon/at After When After + recurring frequency**, then notices will stop being sent when the fee/fine is closed (either by returning the lost item, or by renewing the lost item, or by taking a fee/fine action that closes the fine).	Scheduled	Addition with Poppy: Option 1 for days, weeks, months (i.e. long-term loans): Send overnight with multiple lost item charges by patron. These are processed overnight (11:59 PM) Template must contain reference to multiple loans: {{#feeCharges}} {{/feeCharges}} 100 notice/loan records are processed every 2 minutes. Option 2 for minutes, hours (i.e. short-term loans): Send throughout the day without multiple lost item charges. These are processed every 5 minutes throughout the day. Template *must not* contain reference to multiple loans: ~~{{#feeCharges}} {{/lfeeCharges}}~~
Lost item returned - fee(s) adjusted	Lost item fee adjustment, such as remove processing fee, when the lost item is checked in (if applicable, as configured in the lost item fee policy). For set cost, both aged to lost and declared lost. Addition with Poppy: also for actual cost.	N/A - Always sent when event is triggered.	Scheduled (Yes, this is technically a scheduled notice, even though the UI shows "Always sent when event is triggered.")	N/A - No option.	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.

Browser not supported