Campus Delivery Integration Into EBSCO Discovery Service (EDS)

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).

Campus Delivery Link in EDSWhen 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.

Routing Rule "t.CitedIn = 'EBSCO:cat(yourcatalognumber)'"


Campus Delivery Website Changes

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

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:

html code used for user registration: repeated in the text<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 &nbsp;&nbsp;<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.


The backend of Campus Delivery

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.

  1. User submits a request for a book the library owns
  2. 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.
  3. 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.
  4. If our library has the item on our shelf, ILL staff no longer cancel the request.
  5. Staff route the request to the queue Awaiting Stacks Searching in Doc Del.
  6. 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).
  7. The book is retrieved using the call number on the book.
  8. “Update Stacks Search” is clicked in ILLiad’s Doc Del
  9. Transaction numbers are scanned to update requests and route them to “Awaiting Customer Contact”
  10. In “Awaiting Customer Contact” staff select “Send Automatic Emails”
  11. 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.”
  12. 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.
  13. 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.