Automate actions for new lending requests to ensure consistent processing
Lending automation allows you to consistently and predictably process lending requests according to your stated policies. You can choose to apply designated lending constant data records based on:
• the identity of the borrowing library,
• the type of request, or
• the material format being requested,
This ensures that lending charges, notes, policies, and addresses are accurately applied to lending requests, saving you time, and ensuring compliance with your library’s local policies and preferences.
Preparing for lending automation
- Make sure your library has lender constant data records configured for the combinations of loan periods, charges, return addresses, and lending notes you regularly use. Here are a few examples:
- Fees. If you charge different fees to different libraries, make sure you have a constant data record for each of your typical Lending charges.
- Loan periods. If you have different loan periods for different formats or different libraries, make sure you have a constant data record with different Due Dates for each of your typical loan periods.
- Shipping/mailing addresses. If you have different shipping/mailing addresses you want borrowers to use when returning your items, make sure you have a constant data record for each of the mailing addresses you may want borrowers to use.
- Shipping methods. If you use different shipping methods (e.g., a courier with some libraries, Express shipping in some cases, and mail the rest of the time), make sure you have constant data records that have appropriate Return Via entries representing shipping methods and Return To: addresses that are correct for each shipping method.
- Setting up custom holdings groups. If you want to charge different borrowers different fees, either based on their membership (or lack of membership) in a reciprocal group or based on a "we charge what you charge" relationship, make sure to create a custom holdings group (CHG) for each set of symbols you typically charge a given amount. (e.g., There are 50 libraries you have borrowed from in the past year that all regularly charge you $10. Create a CHG with those 50 symbols and label it "Charge10.")
- Updating Policies Directory. Ideally, your policies applied through automation (charges based on format or requesting group; loan periods; shipping methods) should match what is stated on the Policies tab in your OCLC Policies Directory entry. This is a good time to check your stated policies and make any updates so that actions applied through lending automation are aligned with your stated policies in Policies Directory.
Configuring lending automation
Lending ARM (Automated Request Manager) is now an additional tab on the Automated Request Manager page in Service Configuration.
Just like with borrowing automation, the top of this page displays a list of standard actions that happen when your library is about to be assigned the lending request.
Main Automations
Under the table of standard actions, you can configure main lending automations.
When creating a new lending automation, the automation is enabled by default. The enable feature is currently only available in lending automation. Unchecking and saving the automation will disable the automation without requiring you to delete it.
Just as with borrowing automation, each automation is required to have a Name, Priority, and at least one Action. Automations that specify actions but no Matches will match all requests.
The Name field can accept alphanumeric values, symbols, and spaces, with a limit of 40 characters.
The Priority field allows you to specify, in the case of a request matching multiple automations, which automation should be applied. For this reason, it is recommended that you give the most specific automations the lowest priority score.
Available Match Criteria ('Matches')
- Borrower group
- You can select from a combination of custom holdings groups and profiled groups to define rules for. This allows you to create custom holdings groups that reflect a group of libraries that should all be charged the same amount or should all see a return address making use of a courier or different shipping service/address.
- Formats
- Formats refer to the material format of the item, and you can select one or multiple formats. This is useful if you need to identify requests for item types that have a different loan period, notes, or lending charges or restrictions (e.g., I lend books for 12 weeks but I lend AV for 30 days and I require you return these items in a padded envelope).
- Request type
- Allows you to specify copy or loan requests. If no request type is selected, the automation will apply to both copy and loan requests.
- Matching is not case-sensitive.
Available Actions
- Apply Constant Data
- You can apply a designated Lender Constant Data record as an action.
On the main lending automation screen, you can easily see which automations are enabled, as well as their match(es), action(s), and priority.
A note about constant data persistence
In order to keep constant data persistence from overwriting the work done by lending automation, constant data persistence will now be disabled on lending requests where automation has taken an action to apply a constant data record.
If you have constant data persistence turned on in Service Configuration and an automation has taken an action to apply constant data on a request:
- Persistence will be disabled on that lending request
- A warning message will appear in orange at the top of the screen alerting you that constant data persistence is turned on but has been disabled for the request.
If you have constant data persistence turned on in Service Configuration and an automation has not taken an action to apply constant data on a request:
- Persistence will operate as usual
- No warning message will be displayed
It is our recommendation that libraries not use constant data persistence. Instead, you can handle the application of constant data (both borrowing and lending) via automation. Both Borrowing ARM and Lending ARM allow users to establish automations that predictably and correctly apply specified constant data records.
Lending Automation History
In the staff interface on the Request Details screen under Request History, all lending requests will now have an Automation History section. This section is the first section that appears under Request History. This section will record:
- The time stamp for when the lending automation event was processed.
- The name of the matched automation (or that no automations exist or that there was no matching automation).
- The success or failure of constant data being applied.
For more information, see Automated Request Manager.