Driver | SILS Ops Center (SOC) |
Approver | RS OST |
Contributors | SOC, RS OST |
Informed | SILS Ops Center (CDL) |
Objective | Enable SOC to conduct system-wide resource sharing testing in Alma sandbox environment |
Due date |
|
Key outcomes |
|
Status | NOT STARTED / IN PROGRESS / COMPLETE |
\uD83E\uDD14 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
Must have |
|
|---|---|
Nice to have | |
Out of 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.
\uD83D\uDDD3 Timeline
\uD83D\uDEA9 Milestones and deadlines
- Alison Ray (CDL) Define/create documentation structure (how to communicate created accounts to SILS Ops Center)
DONE: RS SB Testing Accounts (cohort only)
- campus RS OST: Decide on account access level
- campus RS OST + sys admin(s): Create accounts
- Alison Ray (CDL) Document sandbox refresh procedure
- everyone: Test sandbox refresh procedure (after August sandbox refresh) //pick date after ExL announces Aug refresh date
\uD83D\uDD17 Reference materials