Skip to content

Group and Local Library System Needs

Private Academic Library Network of Indiana—Last revised in August 2016 by Noah Brubaker

Group User Management Needs

  • Ability to grant roles to members of group to provide access to home institution interfaces. This functionality would include searching for established group members and granting roles and creating local users for external group collaborations. 
  • Ability to report across the group based on role. 
  • Ability to search for users based on role. In a group situation this functionality must exist.
  • Ability to log in to other instances easily. Perhaps via a dropdown similar to a “branch” views.
  • Ability to report on user activity of those granted roles but outside the institution.
  • Ability to use more than 1 authentication source such as CAS/LDAP and system accounts.
  • Ability to identify partners at the institution level for “Ad Hoc” groups which only provide access to resources shared between the two institutions and NOT the group (ie. External partner could not see patron information of larger established group).

Local User Management Needs

  • Ability to search for and report on users based on role.
  • Ability to use more than 1 authentication source such as CAS/LDAP and system accounts currently even creating testing accounts is time consuming.
  • Ability to update and change most or all fields in user profile via patron load.

Group Collaboration Examples

One to many

Within PALNI we have individuals who are hired at the consortium level and require the ability to access each institution's system to make necessary changes or perform a task. Currently we are working with each institution on a case-by-case basis to establish an account, sometimes locally, sometimes via LDAP/CAS which also often then requires working with campus IT in order to establish. Once the lengthy process is completed then we must collect and record each individual login which often has a varying username and password requirement. Only then can we ask the institution librarians to grant the necessary roles to the account. Functionally, the user must then log in and out repeating the process for each institution.

One to one (or several) within group

This use case will be more common for us moving forward. In this scenario we have an institution collaborating with one or several others, typically around performing a task, such as cataloging. So we have a cataloger that is performing work on behalf of one or several institutions and would require access between their home and the partner institution.

External partner

In this case we would be looking to partner with an external institution either on the same ILS/LSP or not.

  • If on the same ILS/LSP, the creation of an ad-hoc group by an individual institution would be ideal allowing for a choice of what to share (patron database, collections, etc.) or only create an institutional connection with specific named people allowing for role sharing and an easy toggle between institutional views
  • If external partner is on a different ILS/LSP this would be addressed via local user creation or third party authentication mechanisms for named people. In this instance the external partner could either be added locally (likely most common) or authentication could be set up to query their originating institution.

Group workflows

The use of a local and group workflow manager or dashboard would improve the ability for remote collaboration (or internal department collaboration) to occur within an ILS/LSP system. The workflow manager should have the ability to define and trigger events, prompts, or alerts to individuals or modules within the system. This type of workflow management becomes increasingly important as collaborations extend beyond a single office.

Example: A new database has been acquired by the library. Once the acquisitions librarian has completed her last step in purchasing, the workflow manager takes her to the appropriate screen to upload a copy of the license agreement and places a note in her dashboard, should she opt not to upload immediately. A notification is delivered to the identified manager of the knowledgebase down the hall, to activate the resource in the KB. Once the Acquisitions Librarian uploads the license the workflow manager then triggers an alert to appear on the dashboard of the License Manager Librarian, working remotely and employed by the consortium, to code into the license manager tool.

Local Licensing

License management tools need to be flexible enough to allow for various workflows across staff within a local environment. We have some currently identified needs for license management.

  • As noted, some libraries within PALNI have not fully implemented a tool for both license management and usage data harvesting, and so these libraries continue some workflows using spreadsheets, etc. Library staff would like their efforts to encode licenses and configure usage data harvesting to result in the ability to monitor costs for electronic resource acquisition as well as the ability to compare license terms and evaluate patron usage in order to assess the value of particular resources, so that libraries can clearly articulate the ROI of the electronic resources in which each library is investing significant funds and staff time.
  • How cost-per-use functionality will be incorporated at both the title level and collection level is unclear at the moment. Including clear indicators that cost-per-use functionality will take full advantage of data connections from a license management tool to the other system modules would encourage deeper use of a license management tool for individual PALNI libraries.
  • Full access to COUNTER reports in a reporting environment is essential to making the usage data harvested available to support decision making and analysis at individual libraries. PALNI has submitted two enhancement requests related to greater functionality for COUNTER reports:
    • A request for expanded COUNTER report data availability in ILS/LSP for reports such as cost per use.
    • Built in canned/standard reports utilizing counter data.
  • Utilize the library community and expertise to develop licensing terms within the system.
  • API access to license terms is desired to allow local and 3rd party development and integration to occur enhancing the value of licensing data/terms.

Group Licensing

  • Access to COUNTER reports from the entire group that could be incorporated into canned reports or custom reports would facilitate comparison of electronic resource usage across PALNI, which would support efforts of libraries to demonstrate the value of these resources when compared with peer institutions.
  • The ability to configure alerts regarding shared licenses from the originating library to library staff within the libraries who have accepted the shared license would help the libraries utilize workflows that depend on the use of these alerts.
  • The ability to search and find both local and group licenses from the same search interface.

Local Reporting Needs

  • Report delivery that is flexible is a strong desire for many of our libraries. The ability to Email, FTP, or deliver reports in other ways that also allow for reports to be delivered to anyone and scheduled.
  • The ability for many different types of users with varying system credentials to run reports is critical. Generating a custom report to then be shared with Circulation Staff (perhaps student workers) without needing to grant access to a particular module is something that many libraries wish to do.
  • API (or ODBC or other) level access to reporting data would provide the ability for local libraries to create dashboards, web embeddable reports, and analytical applications to use report data. The development of an API would allow library staff, administration, and users, as well as campus staff and administration, a level of access to the library not possible before. As the need to report back ROI and assess the library grows having the ability to clearly, quickly, and currently display important metrics is highly desirable. The ability to create widgets directly from the reporting environment would also be a convenient way for libraries to provide some level of access to this information in a convenient way. Campuses are exploring data collection and analysis in conjunction with other campus data stores. Libraries will need to have the ability to participate in these projects or risk not having the ability to prove ROI and educational impact via the campus defined methodology.
  • There are several reports identified as “Holy Grail” reports, which are required by many institutions for annual reporting to external bodies, accreditation reports, and potential future canned reports. Of primary interest is the IPEDS report; providing this report as a canned option would provide a solution to a problem each library needs to solve every year, typically at great expense of time and effort. Additional reports could include New Titles lists updated daily and Newly Cataloged lists updated daily and with an option to scope for subject area.
  • Exporting data for offline manipulation in external systems has been requested. This goes beyond running a report and saving the results and requires larger comprehensive datasets typically with a long historical view. Creating reports using data from multiple systems is becoming a necessity as libraries are looking to hone their collections, user experiences, and provide assessment and ROI information. Enabling libraries to download datasets will allow for work to be done with other campus systems, such as the student information system and the learning management system, as an example.
  • “Bridges” between other products into a reporting environment would further enhance the breadth of scope across what reports we may be able to generate. The would include the ability to accept data exported from other systems or API access to pull data in from remote sources or pull data our from a remote reporting tool.

Group Reporting Needs

The items outlined in “Local Reporting Needs” are similar to the group needs and options available at the local level and should be available for groups in addition to the items below.

  • There are many reports that PALNI and other defined groups would have interest in running across institutions or subsets of institutions. Reports to determine similarities or differences between various definable institutions would provide a unique window in how libraries are operating based on policies, collections, demographics, etc. This information would be invaluable to better serve our patrons and to determine strengths and areas for growth across multiple institutions.
  • The ability to easily share report templates would allow one library, creating an interesting report to share that work out with others to take immediate advantage of. Without this functionality, each library has to create reports on their own, likely duplicating efforts for many reports and for reports desired to provide comparisons between libraries. Additionally, within PALNI, reports created centrally by PALNI Coordinators should be easily shared to provide a way for the consortium to provide reports to the supported institutions.
  • Similarly to the local need to have flexibility in report delivery, reports run at the group level should be able to deliver results to each member library via a shared folder, email, or within the system. This would allow for central running and results to be provided without requiring each report to be run independently.

Group Circulation Needs

Configuration

We suggest that configuration be split into two levels: a local level for configuration decisions involving local patrons/local materials and a group level to configure policies for patrons borrowing materials from other libraries in a group. Each library could add “group permission” to particular patron classes and item locations/statues. A library should eventually be able to give multiple group permissions to a patron or item class, enabling the library to participate in more than one group circulation arrangement. It should be possible for a group level administrator to set policies for all patrons or item classes that have been added to the group.

In addition, analytics for a group circulation system as a whole should be visible both at an administrator level and at a comparison level for individual libraries. Having a picture of the overall system is important for all parties to perform basic quantitative assessment on the service.

For reasons ranging from relationship management to our patrons’ levels of familiarity with various library locations in our group, we feel strongly that all automated communication be derived (branded/personalized) from the patron’s home library. The library should set the communication templates for all messaging with their own patrons. The patron’s home library should control permission to modify or cancel a patron’s request. Other libraries should not be able to cancel or change a patron’s request without the permission of the patron’s home library.

Patron Interface

We believe that as much as possible, there should be a unified fulfillment button that decides the best fulfillment option without confusing the patron. The button should be located in a single predictable and accessible spot, no matter what fulfillment path is being followed. PALNI is in the beginning stages of development a single fulfillment button that would load a menu with the best fulfillment option highlighted.

We believe that libraries should be able to brand their fulfillment button(s) with text that makes sense in their local context.

Finally, patrons should have the ability to express choices and preferences about which materials they need. Patrons should have the option to choose which item they need from a multivolume set. Patrons should also be able to identify a particular edition preference (or lack of edition preference) and send a note to library staff if desired.

Staff Interface

The staff interface needs to continue development along “lean” principles. Workflows should be consolidated and streamlined wherever possible. Additional work could be done to integrate group circulation with ILL workflows. A single unified pull list and processing workflow for all requests in the platform would be tremendous. The ability to auto-generate appropriate custom labels for items to minimize processing steps would also be ideal.

The system needs to expose and interact with data in robust ways via APIs. Due to libraries’ multiple affiliations and the usage of a variety of automation systems in these libraries, group circulation needs to be able to interact cleanly with other systems via API. Passing requests to and from ILL systems (e.g. ILLiad) or consortial borrowing systems (e.g. Relais ILL) is a part of the fulfillment ecosystem functioning at an optimal level. PALNI may eventually have specific advice on data points that should be exposed via API.

Library staff need to be able to intervene on requests and move them between fulfillment paths or from one bib/item record to another while communicating accurately with patrons. For example, staff should be able to cancel a group circulation hold request and make it into an interlibrary loan request or vice versa, without triggering automatic notifications that may be confusing. Libraries should also be able to move requests from one bib record or item to another without “cancelling” the request. Development might be done to create a general category for a “Fulfillment request” that could be handled or processed in a variety of ways, with logic built-in that could choose automated handling wherever possible.

Finally, the staff interface needs to make administrative data about current and previous requests readily accessible. Staff need to be able to look up all requests on their patrons and items and quickly see relevant information they need for their work. Statuses of all requests should be visible to patrons and easy for staff to look up. Staff should also be able to configure system alerts for “problem” requests (overdue, misdelivered, etc.)

Patron Interface Detail

Fulfillment button for library patrons

Library patrons should be presented with a single fulfillment button. The button should be designed to authenticate the user and present them with a simple, consistent fulfillment choice that sets appropriate expectations.

It should be possible for libraries to only present a fulfillment option for group hold requests when there is an available copy that permits holds for the authenticated patron. When there is no available requestable copy in the group, the request should automatically be for another channel like traditional ILL. Patrons should not be overwhelmed with a choice of several buttons and error messages when a request is not possible.

Integration with alternate fulfillment

We would like to see a way for group circulation requests to move between fulfillment choices within the staff interface. Sometimes, a group hold request is not the best fulfillment option for the patron. Alternate fulfillment paths include traditional ILL and purchase on demand.

Idea 1: Library staff would see a queue of hold requests that have been unfilled after a configurable waiting period. Staff could then choose to move the item to acquisitions or to a traditional ILL system like ILLiad or WorldShare ILL. This process should trigger an optional configurable notice alerting the patron that the item is being filled through a different method and informing them of the new timeframe. We would also like to see a button to export bibliographic and patron information into ILLiad, WorldShare ILL, and an Acquisitions module to automate the request placing process.

Idea 2: Build a “Fulfillment request” that could be handled through group circulation / hold requests, interlibrary loan, on demand acquisition, or any other fulfillment path determined by the library. Libraries could set criteria for handling the request based on which other libraries owned the item, availability within the group, cost to purchase a copy and warehouse status (e.g. from Amazon API).