2017-03-02 Resource Access Meeting Notes

Date

Attendees

Discussion items

Time
Item
Who
Notes
55minDiscuss Workflow DifferentiationAndrea
5minlayout agenda for 3/6/17 meetingAndrea

 

 

Meeting Notes

Began review of the document Use cases for a workflow engine, and went over differences and similarities for each topic:

1) Office delivery / cross campus delivery / paging 

Three different tasks. Andrea pointed out that 'Paging' probably would be the most common, except that Chicago, Cornell and Lehigh doesn't do 'Paging' (see more notes in the document).

  • Deb mentioned 'Ubiquitous return', the possibility for a patron to return where ever the patron wanted to. 
  • Andrea added the category: 'Transitting' - in a case of floating collections.
  • Joanne explained the 'Request' option, which enables patrons to do requests in Cornell's catalog. This cover the feature to choose campus delivery. Cornell have se up a grid for which libraries have responsibility for which delivery. This solution is solved outside of Voyager is kind of chunky, but the patrons love it
  • Mark explained how Lehigh's Office delivery, and Express delivery both are services with an integration point with ILLiad. Office delivery is tracked with Relais software.
  • Rameka went over the workflow of a request, which can be send to different libraries in a prioritized queue. It's all done from TAMU's catalog as manuel processes through ILLiad.
  • Andrea told about UPenn's handling of these tasks. Which are all very manual processes - 'shoe leather delivery'
  • Filip summarized as follows: "Which item type to be delivered to which people - that is the rules to be set":

a) Eligibility

b) Various level of integration, e.g. using the addition framework in ILLiad or more manually processes

c) Various type of notifications to the patrons, e.g. the notifications in Relais

d) Various need of tracking - from completely manually processes to full automation

2) Proxies 

The differences here 

a) Eligibility

    • Almost universal allowance for faculty to designate another person who already has privileges to be their proxy.

    • Variations allow others patron groups to have proxies or allow people from outside the institution to be proxies.

    • If a proxy user loose their own right to use the service, they will no more be able to act for e.g. the faculty member. Both David and Deb pointed out that the faculty member is held responsible for all acts on their behalf.

b) Tracking

  • Mark mentioned the possibility to certify all actions

c) Placing requests vs. Pick-up

    • Chicago: Separate credentialing for the relationship to allow proxies to log in and make requests on their behalf

    • Frequently though, proxies can’t make requests for their sponsors because single sign-on blocks them from

    • Deb mentioned the meeScan software, which Cornell use the notification feature for office delivery. Joanne explained that if a patron use meeScan, this would allow them to get Borrow Direct lend send direct to their offices. Wendy added, that the technology is available but it is quite a problem to rely on patron doing the scanning. Fillip suggested, that the delivery guy could do the scanning, before the delivery in a mailbox. David said, that a FOLIO app which act similar to meeScan would be a great solution. 

Trying to gain a better understanding of Filip's information need: Filip explained that his process is to pose very open ended questions, and by doing so, he is trying to get the SME's to think about how to think about the challenges they face, and how FOLIO can support it - kind of a “double loop learning” approach. Filip don’t have the answers for what the RA people need to specify; so part of the task is figuring out how to specify it.

Next meeting will be on Monday 3/6/2017 at 11 am EST / 5 pm CET.

 

Action items

  • Andrea will convert the document discussed at the meeting including comments into a spreadsheet.