Our library serves several remote field stations that have small unstaffed reading rooms and we occasionally get interlibrary loan requests from researchers at these sites. We generally choose to mail physical items to these users and wanted a way to differentiate and catch these unique requests so they aren’t cancelled or just placed on the hold shelf. Our current solution is to include a “Primary Location” on the user registration form that populates the user “Site” field in ILLiad. This involved several steps.
First, I added these values to the CustomDropDown menu in the Customization Manager (System -> General -> CustomDropDown).
The new user registration and change user information webpages were updated to include the following code:
<span class=”field”><span><b>Primary Location:</b></span></span>
<select id=”Site” name=”Site” size=”1″ class=”f-name” tabindex=”4″>
<#OPTION name=”custom” groupname=”Site” selectedValue=”<#PARAM name=Site>” defaultValue=”MC” defaultName=”Main Campus” />
Once the webpages are edited, the LabelName ultimately displays to users on user registration/information pages.
The LabelValue displays in the user information under “Site.”
Finally, I created a custom queue and a routing rule to send all requests not coming from users on the main campus to their own queue.
The new custom queue is:
QueueName = Remote Site ILL Requests
ProcessTye = Borrowing
NVTGC = ILL
The new routing rule is:
RuleNo = (Pick a number useful to you. It’s actually our last rule because we want the electronic requests to automatically go to the user.)RuleActive = Yes
ProcessType = Borrowing
TransactionStatus = Awaiting Request Processing
MatchString = (u.Site = ‘RS’ or u.Site=’AEC’ or u.Site=’OT’) = Essentially the LabelValues that you want to go into their own queue.
So far this solution has really helped the ILL staff easily identify the few requests that need to be mailed to the remote sites and process them accordingly.
The third technical component of our new campus delivery service involves integrating this service into our discovery layer. This turned out to be fairly easy to implement. Working with EBSCO, I was able to add a link “Request Item from the Library” that takes users directly to our interlibrary loan login (we use ILLiad).
When users login, they are taken to a pre-filled request form. Open url standards allow information such as title, author, date, and ISxN to transfer between the two systems. In addition, to this basic information, the “Cited In” field is filled in with “EBSCO: (catalog reference within EDS).” I used this information to set up a routing rule so that all requests originated from EDS go directly into “Awaiting Request Processing” in Document Delivery. Because we have a Direct Request rule that automatically processes requests with ISBN’s, I made the EDS Doc Del rule the first routing rule. See below for all the gory details.
As part of our campus delivery implementation, two ILLiad webpages (New User Registration and Change User Information) were updated to incorporate the new user information needed.
When users register for an ILL account, they are now given the option to opt into campus delivery as well as provide their delivery location.
New Options on User Account Pages
- The first field, “Would you like books and other physical items delivered to you?” corresponds with LoanDeliveryGroup in ILLiad. Choosing “Yes” selects “Mail to Address” on the backend while choosing “No” selects “Hold for Pickup.”
- The second field, “If yes, Enter your Main Campus Office / Mailbox Location” corresponds with the secondary address field in ILLiad.
- Another field (not shown in the image above) labeled “Primary Location” was added as a dropdown option higher up in the form to capture what campus / research station users were located at. This field corresponds with “Site” in ILLiad and the values were created in the Customization Manager.
- If you are interested in the html code:
<fieldset><h4>Campus Delivery – Faculty/Staff/Graduate Students</h4><label for=”LoanDeliveryGroup”><span class=”field”><span class=”<#ERROR name=”ERRORLoanDeliveryGroup”>”><b>Would you like books and other physical items delivered to you?* </b></span><br /><span class=”note”>* Limited to Main Campus Only</span></span> <input type=”radio” id=”DeliveryGroup” name=”LoanDeliveryGroup” size=”1″ class=”f-radio” value=”Mail to Address” > Yes <input type=”radio” id=”DeliveryGroup” name=”LoanDeliveryGroup” size=”1″ class=”f-radio” value=”Hold for Pickup” checked> No<br /></label><label for=”SAddress”><span class=”field”><span>If Yes, Enter your Main Campus Office / Mailbox Location</span></span><input id=”SAddress” name=”SAddress” type=”text” size=”40″ class=”f-name” value=”<#PARAM name=”SAddress”>”><br /> </label></fieldset>
As you may have noticed in the first image, the service is currently only available to faculty, staff, and graduate students who are located on our main campus. This meant that we needed to create status specific pages for users to update their user information. We created one for undergraduates and left out the campus delivery option. Then we created a page for all other statuses that included the same code found on the new user registration form except for one key difference: the default selection to opt into campus delivery is “Yes” instead of “No.” The reasoning behind this was varied. One, it might encourage users to use the service. Two, if users don’t change the option to “No” but don’t include a delivery location, we’ll catch the inconsistency when the pull slips are printed. Third, and most important, I couldn’t have this field populate with users previous preferences like the other fields do on the page. This inability to populate the information is related to our choice to display “Yes” or “No” to the users as radio buttons as opposed to ILLiad’s values “Mail to Address” and “Hold for Pickup” as drop down menus. Thus far, this minor detail has not been an issue.
As I mentioned in a previous post, my library is implementing a campus delivery program and I just finished setting up the back end to make this process more seamless. Here’s a recount of the changes:
First, I had to define a policy and process for processing holds in our Integrated Library System, Aleph. This involved setting up automatic reports in Aleph’s “job list,” adjusting the print templates, and training the staff. The most frustrating part of the whole process was that I couldn’t determine a way to automatically send email notifications to users letting them know their hold was available for pickup. Well, there is a way to send the email if the circulation computers were set up to send emails through Aleph, but our IT team would never let this happen (and I don’t really blame them.) So, keeping this inability to send “available for pickup” notifications in mind, I moved onto the ILLiad component.
Here’s a rundown of the new ILL process for requests that the library has on the shelf.
- User submits a request for a book the library owns
- The request may end up in the Borrowing or the Doc Del Awaiting Request Processing queues depending on routing rules and how the request was placed.
- Library staff check to see if the item is owned by our library using the z39.50 feature and, if available, staff click “Copy Info” to automatically populate the call number field in the request.
- If our library has the item on our shelf, ILL staff no longer cancel the request.
- Staff route the request to the queue Awaiting Stacks Searching in Doc Del.
- When “Print Pull Slips” is clicked, a slip gets printed based on the template DocDelLoanLabels. This template was adjusted to include the user’s institution ID (as a scannable barcode), Delivery Method, and secondary address (aka campus address).
- The book is retrieved using the call number on the book.
- “Update Stacks Search” is clicked in ILLiad’s Doc Del
- Transaction numbers are scanned to update requests and route them to “Awaiting Customer Contact”
- In “Awaiting Customer Contact” staff select “Send Automatic Emails”
- For books, two different emails can generate. The template ILLDDLoanDeliveryNotify is used for users who want campus delivery (aka: they have a delivery option “Mail to Address”) The template ILLDDLoanNotify is used when users are going to come to the library and pickup their item. This reflects the delivery option “Hold For Pickup.”
- If users are using campus delivery, their item is checked out to them in Aleph using their institution ID number that’s in both Aleph and ILLiad. Then the item is delivered to the specified location on campus as indicated by the user’s secondary address.
- If users are coming to the library to retrieve their item, a hold request is placed within Aleph. Then the item is “returned” in Aleph to actually place the item on hold for the user. Finally, the item is placed on the holds shelf and can be checked out when the user comes to pick it up.
For books our library doesn’t own, the only technological step we needed to change for campus delivery was the print template and an email template. So, I updated the BorrowingLoanLabels template to include the user’s “Delivery Method” and their secondary address (ie: their campus address). I also added and customized the email template ILLLoanDeliveryNotify.
The final technological changes that were made to make campus delivery a success involved altering the website which I’ll discuss in my next post.
I’m in the process of setting up campus delivery using primarily ILLiad (more on that in a future post) and have found some interesting things regarding email templates in ILLiad 8.4.
In 8.4, email templates can reside and be customized in the Customization Manager. This makes updating emails easy … IF the templates were set up correctly to begin with.
To illustrate, I’m going to use ILLDDLoan as an example which is an email meant to notify users that physical items going through Document Delivery are available for pickup.
Looking at the Customization Manager -> Borrowing -> Email -> ILLDDLoanNotifyEmailFileName, I saw that the default Key Value was set to illddloan.txt. So with the troubleshooting mindset that only a few changes should be made at a time, I incorrectly created a new template in “Email Templates” with the name illddloan.txt. Unfortunately, none of my test emails had the new and correct information. I did some further investigation and found the ILLiad 8.4 Guide to Creating and Editing Email Templates – Default Email Templates. This resource pointed out that several of the email templates that I am interested in changing are stored in the ILLiad database and have a specific file name that does not end in .txt. So in my example the file name should be ILLDDLoanNotify not illddloan.txt.
Correct Email Template
I have since made changes to the Email Template names but not the …EmailFileName keys located elsewhere in the Customization Manager. I find it odd that I didn’t have to change the name in both locations, yet am very happy the emails are working well.
One of our staff printers that was used by Interlibrary Loan died recently and I often forget that, in addition to adding a printer to your computer, ILLiad needs to be setup with the new printer. To do this:
- Click the circular ILLiad icon in the upper left hand corner
- Click Printer Setup
- A Print Configurations window should appear with a list of templates that ILLiad client has used to print documents
- In the second column labeled Printer, click on the printer you want to change.
- Select the printer you want to add
- Click Save
This is also the screen where you can adjust the print settings to automatically print or to display the document for editing and manuall printing. Simply uncheck Edit and Prompt to automatically send the documents to the printer without a prompt or the templates appearing.
We are implementing the Getting It System Toolkit (GIST) at our library and the directions on the GIST website are very helpful. However, I did run into a slightly confusing setup issue involving some of the ILLiad addons related to GIST.
So, I followed the steps outlined on the GIST website to install the acquisitions manager. OCLC added the GIST database tables to ILLiad (Step 1). I installed GIST webpages to begin testing (Step 2) and then I installed the following addons to our networked addon directory: GIST for Web, GIST Database Manager, GIST Acquisitions Addon (Step 3). Then I opened the ILLiad client to make sure the addons installed correctly. The GIST Database Manager showed up just fine but when I went to open a record I got the following Lua Script error:
My first reaction was that the addon installation was corrupt in some way, but that was not the case. It turns out that one needs to move on to the next step, Configuring the Database Manager, before the addons will work. In particular, there needs to be at least one budget line created in order for the GIST Acquisitons/Purchasing addon to add the “GIST Acquisitions Addon” and “GIST Purchase Addon” tabs without causing an error. Once a budget line is created, you can update and configure the database manager at your leisure with causing errors for other folks.