Library Independence
Alma Organizational Structure
The organizational structure of an institution(s) and its libraries reflects an understanding of how to achieve the best results when processing each library’s workflows. It must maintain an efficient division of roles and responsibilities between departments, but not lose the benefits of having multiple departments collaborate and share data. It is crucial for the institution to define an organizational structure that is both efficient and reflective of how the library processes will be optimally managed.
Alma supports a number of main organization levels:
- Alma Institution
The Alma institution is the basic level of data and workflow management in Alma. Being the main building block of the organizational structure, it enables consolidated management of key workflows. The institution manages data as a single list, accessible to all institution staff with the relevant roles, for example User management, Licenses, Metadata management, Integrations and more. - Alma Library
The Alma library is comprised of one or more physical locations, each of which is normally housed in a single building or in several buildings in close physical proximity. A library may have several locations within it, such as the circulation desk and digital archiving. Each Alma Institution can have multiple Alma libraries.
In addition to the institution and library organizational levels, Alma provides two additional optional organizational levels - a campus and a collaborative network (a.k.a Network Zone). For more information about Alma organizational structure please refer to Alma Topologies.
Library Independence
As part of an effort to increase specific libraries’ ability to operate in a manner that is more separated from other libraries, several enhancements have been introduced into Alma to increase library independence and to better support the following:
- Small Universities or other organizations that are grouped into a single Alma institution:
This may happen for considerations that have to do with the libraries’ size and ability to maintain a full-scale Alma institution. Being independent libraries, small libraries’ workflows and configurations should be as separate as possible from other libraries. This is especially true with regard to fulfillment workflows where patrons’ privacy is affected in an undesirable manner by having fulfillment data shared with other libraries grouped into the same Alma institution. On the other hand, being a small library with minimal staff, maintaining a full-size Alma institution for every library is a burden. - Independent colleges that are part of a single institution:
While the institution may have shared configurations, workflows and data that make the recommended Alma topology be a single Alma institution, it may be made up of historically independent colleges. For example, these colleges maybe managing the same funds and purchasing scheme but are totally independent when it comes to their teaching and therefore the fulfillment aspects of their workflows. - Institutions that are organized as independent campuses:
Similar to the multiple colleges use case, an institution may be made up of multiple campuses that may be very remote from one another. This simple geographic consideration makes their teaching and therefore their fulfillment workflows and policies independent from one another.
In all these use cases, maintaining a single Alma institution but still allowing greater independence of the libraries will correctly balance the requirement for a single Alma institution with the need of the libraries to maintain their independence.
Fulfillment
Fulfillment and
Resource Sharing
Patrons
Patron authorization and service eligibility is based on the patron role and the fulfillment rules. Both elements are manageable at the library level as follows:
- Patron roles may be assigned at a specific library. In that case, the patrons will be allowed to request and borrow only items that are owned by the library in which they have a patron role.
- Fulfillment Units may be owned and managed by each library independently. In addition, fulfillment terms of use rules may be set per library. This allows each library to create its own rules and policies regarding who can request and borrow what item, and with what terms of use.
- Patron registration at a circulation desk may be done in a way that creates a patron role only for the library where the registration is taking place (‘Currently At’ location of the desk). This is achieved by setting Patron Registration Rules that determine the assigned patron role to be done at the scope of a library (and not the institution). It is also possible to assign separate registration fees for each library. Registering patrons in specific libraries (and activating the relevant registration rules) is also possible using the Create Users API.
It is possible to limit the ability to search for user accounts, so that logged in users will be able to search only for accounts that have patron role that is scoped to a library that the library operator's roles are scoped to. Setting this option is done by using the User Management configuration menu>General>Other Settings menu to set the limit_user_search_by_library_scope parameter to true.
Circulation Desk Staff
Out of the box, circulation desk staff are assigned library level roles and have access only to the circulation desks that a given library has authorized them. However, once logged in to a given desk at a given library, the circulation desk staff can access the following fulfillment transactions owned by other libraries:
- Loan and return items of other libraries (if the library allows that) and override fulfillment blocks of other libraries.
- Pay fees of other libraries.
- Create institution level blocks affecting patrons’ ability to borrow items of other libraries.
- View notes related to other libraries (for example ‘you have items on hold shelf at another library’).
- View letters that have been sent to the patrons from any library.
It is possible to set up more library independence by allowing viewing and managing the following only at the specific library’s scope:
- Loans — Desk operators will see patron loans only if the loaned items are owned by a library that is in their allowed scope, or has been loaned out at a library that is in their allowed scope (as per configuration option).
- Returns — Desk operators will see patron returned items only if the returned items are owned by a library that is in their allowed scope. Note that anonymized loans do not show up in this tab.
- Requests — Desk operators will see patron requests only if the request is managed by a library that is in their allowed scope, for example the item is on a hold shelf of one of the libraries in their allowed scope, or is requested for pickup from a library that is in their allowed scope.
- Fees — Desk Operators will see a balance of only fees that are owned by a library that is in their allowed scope (or owned by the institution). Likewise, they will be able to process (receive payments for or waive) only fees that are owned by a library that is in their allowed scope (or owned by the institution).
- Blocks — Desk operators will be able to view and manage only blocks that are owned by a library that is in their allowed scope (or owned by the institution)
- Notes — Desk operators will be able to view and manage only notes that are owned by a library that is in their allowed scope (or owned by the institution).
- Notifications — Desk operators will be able to view only notices that have been sent by a library that is in their allowed scope (or sent by the institution).
- Statistical Categories — Desk operators are able to view only statistical categories that are owned by a library that is in their allowed scope (or owned by the institution).
In this mode of operation:
- User managers and circulation desk operators will be able to create notes, blocks and statistical categories that are owned by specific libraries.
- Library owned blocks affect only loans of items from the the same library as the block.
- Library owned notes are viewable only to circulation desk operators for whom the library is in their allowed scope.
- When statistical categories have been used as input to fulfillment rules, they will affect only loans or requests of items from the the same library as the statistical category.
- Circulation desk operators will be able to renew patron roles only for libraries that are in their allowed scope.
- Circulation Desk Operators' allowed scope is determined by the libraries in which they have an active Circulation Desk Operator/Manager role.
See more information on the Fulfillment Library Independence document.
Setting up the required model of library separation is done by Ex Libris. Please contact Ex Libris support to activate a desired model.
Patron Notifications
It is possible to set the system to send separate library level notices for notices that are currently an aggregation of multiple libraries. For example it is possible to set up the Borrowing Activity Letter, which is out-of-the-box a notice that aggregates information from multiple libraries, so that a separate Borrowing Activity Letter will be sent by each Library. It is also be possible to set separate logos for each library, so that notices sent by different libraries may be differently branded.
This can be done by enabling the separate_patron_notifications_by_library customer parameter.
For more information see the Library Level Patron Notifications video.
Request Operators
Request operators, like circulation desk staff, are assigned library level roles and have access only to the circulation desks that a given library has authorized them. The pick from shelf tasks that these operators have access to is limited to those that are managed by the library in which they have been granted a role.
It is possible to set up more library independence by setting the Requests Monitor to be filtered by library ownership. This way, only requests managed by one of the libraries in the operator’s allowed scope are viewable.
Request operators' allowed scope is determined by the libraries in which they have an active Request Operator role.
See more information on the Fulfillment Library Independence document.
Setting up the required model of library separation is done by Ex Libris. Please contact Ex Libris support to activate a desired model.
User Managers
User managers have access to the full institutions’ user list, including access to every users’ blocks, notes, fees, statistical categories and notifications, regardless of the library to which they belong.
It is possible to set up more library independence by setting user manager roles that are at the scope of a library and therefore have access only to blocks, notes, fees, statistical categories and notifications of their scoped library or libraries.
The user record itself (core and contact information) is shared, managed at the institution level and is updateable by any user manager regardless of the role's scope.
See more information on the Fulfillment Library Independence document.
Setting up the required model of library separation is done by Ex Libris. Please contact Ex Libris support to activate a desired model.
Fulfillment APIs
It is possible to set the “API Restrictions” integration profile to limit API access to Fulfillment APIs by library. This includes:
- User APIs - Loans, Requests, Resource Sharing requests, Fines&Fees
- BIB API - Loan and requests
In either case -
-
GET APIs will filter only entities which are in the relevant libraries.
-
POST/PUT/DELETE APIs will return an error if the entity isn't in those libraries.
For more information, see: Working with API Restriction Profiles in the Developer Network.
Fulfillment Administrators
It is possible to limit users with Fulfillment Administrator role to manage only specific libraries. Limited administrators will be able to access and update only configurations that affect their scoped library.
User Management
User Search
It is possible to make the core user information searchable only to allowed library operators. When set up this way, users of a library are searchable only to library operators of that library. This achieves increased privacy by having the ability to separate the libraries' patrons list from one another.
Electronic Resource Management
Electronic
Resource Management
Management of electronic resources includes the ability to update/delete/add electronic collections/portfolios whether as a single action or batch processing.
Electronic resource ownership can be defined at the level of the institution or at the level of the library. Electronic inventory operator roles can also be associated with library scopes. Users with electronic inventory operator roles with a library scope are limited to managing only the electronic resources that are owned by libraries under its scope.
Users with electronic inventory operator roles with an institution scope have the privilege to manage any electronic resources in the institution regardless of the electronic resource library ownership. This way, libraries can manage their electronic resources independently from other libraries in the same institution.
Physical Resource Management
Physical items and holdings records are always owned by a given library. The Repository Manager and Physical Inventory Operator roles, which have update and withdraw privileges to items and holdings, may be scoped to specific libraries only. When scoped to specific libraries the operator can only update items and holdings that are owned by the libraries that are included in the operator's roles.
Acquisitions Workflow
Libraries can manage their funds, invoices, purchase orders and purchase requests separately from one another. Additionally, each library has the ability to define a price threshold for their automatically created PO Lines as well as amount threshold for their automatically created invoices, and to create rules for Alma to notify and act upon cases where the price/amount threshold was reached.
Vendors are jointly managed by the institution (all privileged operators at the institution can view them), but can be made available for use only by specific libraries. Libraries may therefore create purchase order lines and associate them with vendors (suppliers) that are not shared with the rest of the institution.
Acquisitions entities take into account the user role's scope. In cases where the user role's scope is limited to a specific library, users will only be able to create PO Lines or invoices for the scoped library, manage funds of the scoped library and associate vendors for the scoped library.
Alma has a direct relationship between Acquisitions and Resource management. PO Lines which are owned by a specific library will create items/holdings for this specific library only (with the exception where a library has a relation to "acquire for" another library).
Discovery and Patron Services
Primo includes granular setup within an institution that allows patrons to have a different experience per multiple libraries or campuses. This include creating multiple views, each with their own branding, look and feel and general view setup (such as facets and display fields definitions etc.) and the scope of what they are searching.
Institutions working with Distributed Access to Electronic Resources in Alma, can expose only electronic records relevant to their campus/library as well as manage separate CDI activations for the distributed library or campus within the institution.
There are elements that are defined once at the institution level in Primo and will define the same behavior and options to all users and libraries within the institution. Having one single institution means that these are defined once, as opposed to multiple institutions where on the one hand these need to be configured multiple times, but on the other hand allow each institution to have their own definitions.
- Ranking — Changes to search ranking is defined at institution level
- Patron Authentication – This is defined once at the institution level and all users attempting to sign in will see the same options. An institution may offer the patron multiple authentication options to choose from (such as one option for staff, another for patrons and a third for alumni or another campus), yet all users will see the same options.
- Normalization Rules and local fields — In the Primo institution level an institution can add or change the out of the box metadata normalization routines to define what metadata elements will be searchable or displayed and how. Note that when adding new fields, each library view can define whether they wish to display the fields or not, but the content of the field is defined at the institution level.
- Request forms configuration — Fulfillment request form definitions, whether the labels or fields to appear in the form are all managed at the institution level.
- Collection Discovery — Institutions using the Alma collection management can expose the Primo Collection Discovery. This is managed at an institution level, so all the materials seen will be seen from all the library/campus views.
- Course information — Courses and reading lists are managed at the institution level, so a record that is associated with a course will be marked as part of the course, and have the course information seen, whenever the record is found in a view.
- Get it Patron experience – Within a single institution, the Primo views can be mapped to specific libraries so that the patron will see all the physical locations of that library. A special filter will enable expanding the view to see other libraries. In a multi-institution with an NZ case, the patron will see their own institution holdings and item, and below that a list of the institutions holding the record. They can then select an institution other than their own to see the holdings details.
Digital Inventory Management
Digital resources are organized in Alma in a three-tiered hierarchy:
- BIB
- Representations
- File
Representations and their underlying files are owned by libraries, which means that each representation can only be created and edited by a user with necessary roles and privileges in the scope of the representation’s library. However, users with digital privileges can view all representations of the institution, regardless of the owning library.
Representation libraries are indexed, allowing creation of logical sets of digital sets, based on the library ownership of the contained representations. This will allow running processes such as publishing in scope of a library.
Access right policies can be applied on a representation level, defining who can access the resource and how. The policies are defined at the institution level, however access can be defined by user groups.
Analytics
Analytics Designers can create reports for their colleagues, which are limited to a specific pre filtered library. By doing so, they will not expose information of unauthorized libraries.
In order to restrict reports/dashboards (DV is excluded) to a specific library based on the roles the colleague is affiliated with, each relevant subject area includes a pre-made "Out of the box" Filter called "Library code active filter". This can be added by the Analytics Designer role while creating reports.
Once a report has been created it is then shared via a unique role in Alma, designated for analytics viewers that are limited by a library scope. This role is called in Alma Library Level Analytics Consumer and can be added to any given staff member to allow them to run reports for all the libraries their roles are affiliated with.
Once the filter is added to the report, it filters out all libraries, except for the specific active library codes predefined by the Alma user library permissions. The design role who designs the reports is able to see all libraries while the "restricted library analytics" colleagues are restricted to specific libraries associated with their roles.
The unique Library code active filter mentioned above appears only in the relevant Subject Areas: "Borrowing Requests", "Dara", "Digital Inventory", "Digital Waitlist", "E-Inventory", "Fines and Fees", Fulfillment", "Funds Expenditure", "Lending Requests", "Licenses", "Physical Items" , "Purchase Requests" and "Requests".