Resource Sharing Testing Sandbox Accounts for SILS Ops Center

UPDATE (Jan 21, 2024): PSB IZ accounts for CDL no longer need to be created proactively after each sandbox refresh.

reasoning: In reviewing the upcoming (Feb 11) Alma sandbox refresh protocols, we’ve determined that CDL hasn’t been using these sandbox accounts and so don’t feel the need to have them pro-actively added after each refresh.

CDL remains open to working with campus colleagues in IZ sandboxes, and so will leave the page up (with a note that the accounts do not need to be added proactively), if you’d like to give us an ad hoc account for a particular project and/or testing scenario.

 Problem Statement

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.

 Scope

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

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.

 Timeline

 Milestones and deadlines

 Reference materials

(Post Go-Live) Enable System-WideResource Sharing Support

RS SB Testing accounts (cohort only)