Users in Alma

Users are an important aspect of Alma functionality. The way that an institution chooses to manage its user accounts and authentication is a critical decision during the implementation process. This section describes how user accounts are managed in Alma, how users are authenticated, and how user information can be synchronized with external systems.

A user account in Alma is managed as one of two types:

• Internal users
• External users

Internal users’ details are managed in Alma. They are created manually by library staff and updated within Alma:

External users are stored and managed outside the library’s scope, usually in another system maintained by the institution (for example, in a Student Information System). These users’ information is loaded into Alma and is synchronized on a regular basis. It is possible to update an external user’s information manually in Alma, but these updates are overridden by the next synchronization with the user information system:

How should an institution decide about its user account type? 

An institution that has a system that manages their users (e.g. Student information system), should define the users that are part of that system as “External” in Alma. Users that are not part of that system (e.g. guests, staff) should be defined as “Internal” in Alma. Note that it is possible to have users of both types in parallel. An institution that does not have a system that manages their users (e.g. national libraries) should define their users as “Internal” in Alma.

An user in Alma consists of core user information (such as first name, last name) and the following related segments: identifiers, addresses, phone numbers, email addresses, notes, blocks, and statistics. A user may have multiple occurrences of each segment:

For internal users, the entire user record is considered to be internally owned. This means that it is possible to edit any user information manually in Alma. For external users, the information that was loaded from the Student Information System (SIS) is considered to be externally owned. It is possible to manually edit this information in Alma, but it is overridden by the next synchronization with the SIS. You can also manually add new user-related segments for an external user. Such segments are similar to internally owned segments and are not affected by the synchronization process. However, you can choose to mark segments as external when creating them manually. In this way, you can keep data updated between synchronizations, but also ensure that the data is then synchronized with the SIS.

User roles define a user’s functions and privileges in Alma. Users can have multiple roles.

Roles can be assigned manually for both internal and external users. In addition, it is possible to create role assignment rules, defining the set of roles that should be assigned to certain users. For example, an institution may decide that all the users with a job category of Administration Cataloger should be granted all the cataloging-related roles. When a new user is created—manually, by API or via the SIS load—roles are automatically assigned to this user based on the role assignment rules.

The main users of a library are the library’s staff (who provide services) and patrons (who receive services). The user type in Alma (Staff, Public, Contact) is used for categorizing only. The functions that users can perform in a library are based on user roles. Staff users are assigned roles such as Circulation Desk Manager and Requests Operator; patrons are assigned the Patron role. Thus, by assigning a staff user the role of Patron in addition to staff operation roles, a staff user can also receive services from the library.

Both staff and patrons can be of the internal or external account type. However, patrons are usually external users.

All users in Alma have a primary identifier, which is part of the core user information. They may also have additional identifiers (for example, a student ID, barcode, and so forth).

During the migration and implementation phase, the Ex Libris administrator and institution’s IT staff define the possible additional identifier types.

The User Identifier Type code table (configured by Ex Libris staff) defines the additional identifiers. The User Identifier Definition mapping table (configured by Ex Libris staff) defines other settings for each additional identifier.

Identifier that is used for authentication must exist for all the relevant users.
The identifier that is used as the SIS match identifier must exist for all the external users in order to synchronize their information with the SIS.

Important: The primary identifier is case-insensitive. For institutions that were live on Alma prior to June 2018, additional identifiers are case-sensitive. For institutions that went live from June 2018 onward, additional identifiers are not case-sensitive. For more details regarding case sensitivity of identifiers, please see our detailed blog post.

By default, user records at each institution are unrelated: When a patron from institution A walks into institution B, you must retrieve the patron’s information from institution A as the first step of managing the patron’s activities. The records at each institution contain a hidden field that indicate their relationship, but all identifier fields (such as student ID, barcode, etc) remain non-unique between institutions.

Alternately, Ex Libris can configure that one or more user identifiers are identical throughout all of the fulfillment network’s linked institutions. For example, you can set that a specified user name configured at one fulfillment network institution is automatically configured at the network’s linked institutions. NOTE: If you use the same IDs to identify students at multiple institutions, ensure that these IDs are unique at all member institutions.

To activate or to modify these settings after they have been configured, contact Ex Libris Support.