Legend: not started IN PROGRESS STALLED decided

Background

The UC Libraries resource sharing system requires a complex set of Alma and Primo VE configurations that are distributed across the 10 institutions, with some configurations maintained centrally in the Alma network zone. Integration of Alma resource sharing with the interlibrary loan broker (VDX) consists of Alma configuration at the institution zone and network zone levels, custom configurations and scripts at OCLC, and a custom adapter service and related data tables maintained by the CDL.

The Alma institution zone configurations are critical to all parts of the resource sharing system, including:

• The Automated Fulfillment Network (AFN)

• Resource sharing partner configuration

• ILL broker integration, including NCIP

Testing, maintenance, and improvement of the UC libraries resource sharing system currently requires coordination among multiple administrators at different institutions, each with different privileges. To troubleshoot or test a resource sharing issue, coordination may be required between fulfillment administrators at two or more UC libraries (for IZ fulfillment configuration), CDL SILS operations (for NZ configuration and CDL customizations), and sometimes system administrators (for such things as IZ library configuration, integration profiles, and allowed email lists). There are currently no staff members at the UC who have access to all parts of the resource sharing system, or who have top-to-bottom expertise in the system, or who are able to efficiently conduct cross-institution tests. This problem severely impedes essential functions at the system-wide level, such as:

• Troubleshooting and analysis

• Testing

• Proposals for system improvements

• Documentation of standard configurations

• Documentation of best practices

The SILS Operations Center at CDL includes people who currently administer resource sharing configuration in the NZ and are responsible for maintenance of CDL resource sharing customizations; they are in a fair position to gain a more holistic understanding of the resource sharing system and to provide system-wide support services, and are able to commit significant time to this activity. We can refer to this role as "resource sharing support analyst."

Recommendation

We recommend that SILS Operations Center identify analysts who can perform a system-wide resource sharing support role, assign them this responsibility, and that the UC libraries takes steps to enable the analysts to be successful. 

To be successful in this role, these analysts would require:

• Accounts in Alma institution zone sandboxes;

• Documented test patron accounts in the Alma IZ sandboxes;

• Additional experience and training in IZ resource sharing workflows and configuration;

• Clear communication paths with campus stakeholders and the SILS structure;

• Clearly defined responsibilities, authority, and expectations for the above access.

Each UC campus would need to determine what level of access it will grant to 1-2 resource sharing analysts in its Alma IZ sandbox, in line with local policies.

In addition, each UC campus will create and document a set of test patron accounts that can be used for Primo VE and resource sharing testing in the Alma sandbox instances.

Levels of Access and Support

Analysts can provide different levels of support, enabled by different levels of access to the institution zones. The UC campuses have varying policies with regard to access to their Alma institution zone sandboxes; however, it seems probable that adequate system-wide support can be achieved without all institutions adopting a uniform policy, provided that in aggregate the analysts have sufficient access to the institution zones.

The following access levels are proposed, with the idea of enabling resource sharing analysts to perform a useful function, while providing enough flexibility to accommodate local policies. The level of service that can be provided by the analysts on behalf of any single institution, and for the consortium as a whole, depends largely on the overall access that they are given to the institution zones.

Level 0: No Institution Zone Access

If no IZ sandbox access is available, analysts are limited to administration of the Network Zone and maintenance of those aspects of the ILL broker integration that are outside of the institution zones. Analysis and troubleshooting of resource sharing patron experience, the AFN, resource sharing partners, ILL broker borrowing requests, and NCIP integration could not be performed without the active collaboration of campus library administrators.

This is the level of system-wide support that we have currently.

Level 0+: Read-only Fulfillment Administration Access

This level of access would prevent the resource sharing analyst from performing any tests in the system, but would allow them to view Fulfillment Admin settings to compare them with other institution settings. Read-only access to general administration settings could be included optionally to allow read-only access to library configuration.

Level 1: Operator Access

If analyst accounts are given Fulfillment Operator and related roles (along with access to test patron accounts), they will be able to independently conduct tests of cross-institution workflows, document these workflows, and perform limited troubleshooting. They will not, however, be able to observe differences in IZ settings that could account for variations in system behavior, and they will not be able to document IZ configuration settings. They would also be limited in their ability to gain institution zone expertise.

Operator roles include:

• Fulfillment Services Operator

• Circulation Desk Operator

• Requests Operator

• Work Order Operator

• Course Reserves Operator

Level 2: Operator and Read-Only Fulfillment Admin Access

If in addition to operator roles, the analyst is granted read-only access to fulfillment admin configuration settings, the analyst will be able to develop some expertise in Alma IZ configuration, observe differences in IZ settings that could account for variations in system behavior, and document IZ configuration settings.

They would not be able to test hypotheses by altering settings temporarily and conducting workflow tests. This would limit their ability to troubleshoot problems and test solutions.

Level 2+: Operator and Read-Only Fulfillment Admin and General Admin Access

This access level is similar to Level 2, but also allows read-only General Admin access. This additional role allows the analysts to see General Admin settings that are important to resource sharing, including:

• Library configuration

• Integration profiles

Level 3: Fulfillment Administrator and Operator

This access level would enable the analyst to temporarily change some settings in the sandbox to understand how the settings affect system behavior. This would greatly increase their ability to independently troubleshoot problems in the sandbox and test solutions.

This privilege would require analysts to get campus administrative approval before conducting any test, to document any configuration changes made, and revert them as soon as the test is complete.

Some settings, such as integration profiles and library configurations, would remain accessible only to a General Administrator. Tests of these settings would require active collaboration with the library system administrator.

Fulfillment administrator roles include (in addition to operator roles):

• Fulfillment Administrator

• Fulfillment Services Manager

• Circulation Desk Manager

• User Manager

• Resource Sharing Partners Manager

• Course Reserves Manager

Level 3+: Fulfillment Administrator with Read-Only General Admin Access

This access level is similar to Level 3, but also allows read-only General Admin access. This additional role allows the analysts to see General Admin settings that are important to resource sharing, including:

• Library configuration

• Integration profiles

IZ Sandbox Access Levels

The following table summarizes the level of access to be provided provided for two system-wide resource sharing analysts by institution:

Resource Sharing Support Analyst Role Boundaries

The resource sharing support analyst role would be explicitly limited in a number of ways to avoid interference with campus autonomy or resource sharing operations. This role, as part of CDL SILS Operations, would:

• Have no authority over or ownership of IZ settings.

• Have no privileges to alter IZ production settings.

• Have no authority to mandate IZ resource sharing settings.

• Inform the local team of any temporary changes made to IZ sandbox settings made in the course of testing, and would revert such changes (unless there is explicit agreement to keep them in the sandbox and replicate them in production).

• Focus primarily on system-wide resource sharing issues, rather than issues manifesting at individual institutions.

• Not be required or expected to synchronize sandbox settings with changes made in production (this remains the responsibility of the local RS administrators).

• Not troubleshoot fulfillment issues unrelated to resource sharing.

Specific policies would need to be established to prevent possible conflicts between tests in the sandbox. In particular all tests should initiate a new borrowing request, never making use of an existing borrowing request. Careful communication is required when changing the circulation status of an item that may be used in another test, or changing the state of a test patron record.

Sandbox Preparation and Documentation

The IZ sandboxes, when properly configured and documented, present a number of advantages for resource sharing analysis and testing, for example:

• Enables a single tester to perform all roles in a test, which greatly reduces the overhead of testing.

• Does not interfere in any way with production operations or statistics, including live patron requests.

• Allows problem requests and other data to remain alive pending Ex Libris consultation.

• Allows controlled experimentation without impacting the production system.

However, effective use of the sandbox requires preparation of the sandbox for testing, including creation of test staff and patron accounts, IVEA configuration to send VDX requests to the VDX test system, and modifications to the sandbox IZ allowed emails list. Sandbox preparation and documentation is necessary for resource sharing support analysts, and is also valuable to local resource sharing teams.

The patron test accounts would consist of patrons of different types (to be defined in detail in the sandbox preparation instructions), who would have privileges to make resource sharing requests in Primo VE and who have walk-in privileges to borrow anywhere in the UC library consortium.

Action Log