Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Library Independence

    Library-Independency1.jpg

    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:

    • 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.png
      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, i.e.:

    • 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. Regsitering patrons in specific libraries (and activating the relevant registration rules) is also possible using the Create Users API.

    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 (e.g. ‘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)

    In this mode of operation:

    • User managers and circulation desk operators will be able to create notes and blocks 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.
    • Circulation desk operators will will be able to renew patron roles only for libraries that are is 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 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 and notifications of their scoped library or libraries.

    The user record itself (core and contact information) is shared, managed at the institution level and 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.

    Electronic Resource Management 

            Electronic Resource Management.png
             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 resources 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 manage 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 Resource Management.png
              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 does can only update items and holdings that are owned by the libraries that are included in the operator's roles.

    Acquisitions Workflow 

    Acquisitions.png
    Acquisitions

    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 had reached. 

    Vendors are jointly managed by the institution (i.e. 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 it 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 that 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 1 single institution mean that these are defined once, as opposed to multiple institutions where on hand these need to be configured multiple times, but 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 1 option for staff, another for patrons and a 3rd 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: when adding new fields, each library view can define if 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 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 a NZ case the patron will see his own institution holdings and item and below a list of the institutions holding the record and 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
    • Represenations
    • File

    Representations and their underlying files are owned by libraries, which means that each representation can be created and edited only 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 on the institution level, however access can be defined by user groups.

    • Was this article helpful?