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 and Primo topologies are highly interconnected. Topology decisions of one system affect the topology decisions that should be made for the other. Both systems can be deployed in several ways in consortia environments, providing the capability for a consistent information environment across all institutions. The central office distributes and delegates administrative responsibilities to specific individual member institutions, and allows individual member institutions to retain affiliation/identification of certain data within the shared environment.
Understanding these systems' capabilities and their dependency on the organizational structure is key to a successful implementation process.
Organizational Levels and Alma Topologies
Alma (and Primo, which is configured accordingly) support a number of main organization levels:
- Alma Institution
- Alma Library
The Alma institution is the basic level of data and workflow management in Alma.
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. (These two optional levels are used only in specific cases, as described below.)
- A campus is a group of libraries. Every library can optionally belong to a single campus (see Managing Campuses).
A campus is used to manage:
- The discovery of electronic resources within campus libraries (see Configuring Distributed Access to Electronic Resources)
- The priority of discovered physical resources and the physical location from which discovery is being made
- The allowed pick-up location of a physical resource
- The collaborative network is a group of institutions that coordinate and share data and processes.
Some collaborative network features require Alma’s Network Zone (see Introduction to the Network Zone). Others require implementing a fulfillment network (see Fulfillment Networks) or a resource sharing network (see Resource Sharing Workflow). A collaborative network may incorporate one or more functions that include:
- Shared Catalog – A shared Metadata Management System, where institutions and libraries contribute and make use of a single shared catalog
- Acquisitions Network – Where institutions and libraries share/manage a joint acquisitions process and shared electronic inventory
- Fulfillment Network – Where institutions and libraries share fulfillment services, enabling patrons of a member institution to directly request or return items at other member institutions in the network.
A fulfillment network can also be set up for individual institutions that are not part of a consortium.
- Resource Sharing Network – Where institutions share resources through ILL
The Alma Institution
The Alma Institution is the main building block of the organizational structure. It enables consolidated management of key workflows. The institution manages the following data as a single list, accessible to all institution staff with the relevant roles (authorization):
- User management – Alma handles permissions via role-based management. The system includes an out-of-the-box set of roles relevant to library management (for example, Acquisitions, Fulfillment, and so forth) while also allowing for the definition of role profiles that represent a predefined set of roles. The use of profiles decreases the need to redefine the roles and privileges for each new user, and also enables bulk update in case of a change to the profile. While Alma offers granular permissions functionality, the interface for configuring permissions is intuitive and easy to use.
- Vendors – Vendor records hold information about the vendors from which purchasing of physical or electronic resources is handled. This includes attributes such as the vendor's type (material supplier, access provider, or licensor), the used currencies, the libraries that may buy from the vendor, and so forth. The attached vendor accounts include additional account specific information, such as the payment method and delivery and claim information. Vendor records are mandatory in order to be able to complete a purchasing process in Alma.
- Licenses – For licensed material (such as subscriptions to electronic resources), Alma can manage a copy of the license and associate it with the licensed resources. It is possible to associate a specific license with the activated electronic resources.
- Metadata management – The catalog metadata is shared and managed at the institution. All catalogers of the institution have access to the catalog, as per their cataloger role permission and cataloger level. The inventory, regardless of it format (physical, electronic or digital), is manageable at the specific library level.
- Configuration – Various settings such as metadata definitions (e.g. validations), acquisition related definitions (e.g. purchase cancellation reasons) as well as user related definitions (e.g. statistical categories) are managed at the Alma institution level
- Integrations – Alma supports various integration points for interacting with external systems such as: Identity Management, Import/Export to Financial Systems, Import from Student Information Systems. The definitions related to these integrations are managed at the Alma institution level. Please note that in some cases there may be multiple definitions (e.g. Authentication in Alma can accommodate up to 5 different LDAP servers).
- Resource sharing partners – The resource sharing partner records hold attributes of the peer partners with which the resource sharing workflows are managed. Partner records attributes of potential borrowing or lending libraries, such as their communication method and their average time to deliver. The partners are then arranged in partner rota templates which are used to group partner records in functional groups. Although the partners list is managed by the institution, the partner rota templates may be independently managed by each library.
Libraries share the management of many data elements and workflows, as listed above. However, there are many options for libraries to separately manage aspects of their workflows, such as:
- Operator/staff roles
Some staff may be granted roles for working only in the scope of a given library. The roles are listed in Managing User Roles.
- Policies - If libraries have unique fulfillment policies that are not shared with other libraries, they may set up library-level policies.
- Resource sharing rota templates and rules - Resource sharing libraries that have unique rota management requirements can set up rota templates that are independent of the rest of the institution
- Purchase orders – Libraries can manage their acquisitions separately from one another, with each one managing its own PO lines.
- Fund ownership and availability – Funds may be owned by specific libraries and may be made available for PO lines of specific libraries only.
- Vendor availability – Libraries may be able to contact vendors that are not shared with the rest of the institution.
- Invoices - Invoices record actual purchase payments and are linked to the purchase orders and to funds. Invoices can be electronically updated in the system--for example, via EDI--or internally triggered in the system. Invoices can be owned by libraries. Only users with an Invoice Operator role at the library have access to library-owned invoices.
- Inventory – Physical and electronic inventory can be owned by libraries.
Multiple campuses may be implemented when there are geographically dispersed campuses with which patrons are affiliated, and there is need to group fulfillment services for each campus, such as:
- Inventory Control:
- Limiting the availability of electronic resources to specific campuses
- Externally exposing the catalog (via Z39.50) sliced by campus level ownership of inventory
- Limiting allowed patron pick-up locations for requested resources by campus
- Grouping lists of pick-up locations by campus
- Limiting and controlling the availability of other services based on campus-level considerations
The Alma Collaborative Network
The Alma Collaborative Network is a network of Alma institutions connected together to facilitate collaboration/sharing of data and workflows. In some cases a collaborative network requires the Alma Network Zone.
An Alma Network Zone may be set up where one of the following is required:
- Shared Catalog – A shared catalog consists of a single metadata catalog that is shared by all libraries. The single catalog source can also easily serve as the source for a shared discovery experience.
- Shared Acquisitions – Shared acquisitions consists of centralized purchasing of e-resources that are available to the member libraries.
- Centrally managed configurations – Additional functionality can be implemented on top of the Network Zone to facilitate centrally managed configurations for the following:
- Resource sharing – The basic configurations of the resource sharing component may be centrally managed at the Network Zone and shared by all members of the network. This includes a shared list of: Using a consolidated configuration set achieves the goal of unifying the user experience and library back office processing across all disparate libraries.
- Resource sharing partners
- Resource sharing rota templates and assignment rules
- Workflow profiles
- Locate profiles
- Vendors – Vendor records can be centrally managed at the Network Zone. Routine and automatic dispatching of the vendor records to all network members achieves the goal of having a single list of vendors that is used throughout all members of the network but is managed centrally by a single office.
- Mapping tables – Mapping tables govern a variety of system behaviors across all functional elements of the system. Maintaining a centrally managed mapping tables set is key to creating unified and consolidated workflows at the network members across the system.
An Alma Network Zone is not required if only the following collaboration is desired:
- Shared Fulfillment/Circulation – Where institutions and libraries share fulfillment services, enabling patrons of a member institution to directly request or return items at other member institutions in the network.
- Resource Sharing Network - Where institutions share resources through Interlibrary Loan
Further information on the entities that can be managed on each level can be found below.
|Branding (user interface settings)||X|
|Staff user roles||X||X (most fulfillment acquisition)|
|User Management Configuration||X|
|E-Activation task list||X|
|Finance system (ERP)||X|
|Ledgers and Funds||X||X||X (usage)|
|Patron Driven Acquisition (PDA)||X (usage)||X|
|External Search Resource||X||X|
|Integration Profile||X (SRU/Z39/SAML)||X (SRU/Z39/SAML)|
|Inventory||X (electronic)||Bulk changes are done on an institution level||X|
|Link resolver access||X||X||X||X|
|Discovery Interface Display Logic||X||X||X|
|Fines and Fees||X|
|Loan||X||X (can define that only specific operators can work in specific libraries and only certain patrons can loan from there)|
|Remote storage||X (definition)||X (usage)|
|Requests and booking (pickup)||X||X|
|TOUs and policies||X||X||X|
|Configuration||X||X||X (library details, locations, circulation desks and departments)|
|Borrowing requests||X||X (usage, TOU and policies)|
|Lending requests||X||X (usage, TOU and policies)|
|Publishing and Primo|
|(in Primo) Possibility to give its own view||X||X||X|
|Bor info for just this level||X|
|Publishing to OCLC||X||X|
|X||X (by criteria’s)|
Multiple Institutions as a Single Institution
There are two options for implementing Alma and Primo across multiple institutions:
- Multiple Alma institutions with a Network Zone
- A single Alma institution with Multiple Alma libraries
Multiple Institutions with a Network Zone
The advantages of deploying Alma across multiple institutions with a Network Zone are:
- The network organization level provides integrated and shared management for bibliographic records, vendors, licenses, user records, circulation policies, and more.
- Analytics and reporting can be done across all institutions, as well as for individual member institutions (access at the network level is controlled, preventing unauthorized access to data between different member institutions).
- The individual institutions are able to operate on their own when relevant:
- The member institutions can operate with differing workflows, collection profiles, operational requirements, and users.
- The solution is flexible enough to accommodate individual institutional preferences while retaining the ability to eliminate duplicate record-keeping and redundant procedures across member libraries.
- Individual institutions can negotiate and purchase resources on their own, using their own fund and vendor definitions.
- Supports individual member-only purchases, multi-institution purchases, and multiple but not all inclusive purchases.
- Each institution can customize and brand their letters and patrons communication (Alma supports these customization at the Alma institution organization level).
- Future new member institutions are easier to migrate and implement when a multi Alma institution topology is in place.
The disadvantages of deploying Alma across multiple institutions with a Network Zone are:
- There is some overhead associated with managing configurations in multiple Alma institutions (although the Network Zone can be used to centrally manage some of the configurations, and is of a much lower scale than management needed for multiple installations of legacy ILS).
- The different members have the capability to deploy unique policies. This capability might risk existing policy and workflow alignment and standardization across member institutions.
- External applications using Alma’s RESTful APIs may need to perform calls at each member institution in order to update the system data.
Note: this model has been adopted by close to 30 consortia around the world. Most Alma/Primo consortia use this option.
Single Institution with Multiple Libraries
The advantages of deploying a single Alma institution (to represent the entire collaborative network) are:
- Simplified administration, since there is a single Alma institution to administer.
- All collaboration required (including shared catalog and shared acquisitions) can be achieved without the need to administer a Network Zone.
- Creating a single Alma institution will probably drive a process to unify/align policies across all institutions, since it is easier to manage in single Alma institution.
- Implementation may be easier for a single Alma institution, since there is no need to provision and configure separate member institutions.
The disadvantages of deploying a single Alma institution (to represent the entire collaborative network) are:
- All member institutions must share the same patron communications branding (letter customization is the same for the entire Alma institution).
- All members must share management of vendors and licenses.
- All members can see each other's data in Alma Analytics (Alma Analytics cannot restrict data to the library level).
- Integrations and Interface definitions are managed centrally for the entire Alma institution. Individual members cannot manage these settings separately.
- All members must manage their e-resources, activations, coverage, and so forth in a single shared environment, with limited ability to fully separate the data for each member.
Note: This model has been adopted by a small number of consortia.
Topologies for Alma and Primo
Decisions made for determining the proper Alma topology must take into account the relevant Primo topology. Below are the topology relationships between these systems:
|Alma Topology||Primo Topology|
|Single Alma institution||Single Primo institution|
Multiple Alma institutions (no Network Zone) sharing catalog, union catalog, or searching in other institutions
Primo institution for each Alma institution. Each institution manages its own data. Has shared scopes.
|Multiple Alma institutions with a fulfillment network (no Network Zone)||Primo institution for each Alma institution. Each institution manages its own data.|
|Multiple Alma institutions with a Network Zone||Primo institution for each Alma institution.|