Managing Named Users in Alma
This section provides an overview of how user accounts are structured and managed in Alma. It outlines the different account types, role assignments, and permissions that determine access to system functions, as well as key practices for maintaining compliance with named user limits. The guidance also highlights recommended processes for reviewing, cleaning up, and managing user records to ensure accurate access control and system security across institutions.
Types of Alma User Accounts
Alma users can be Internal, which means completely defined in Alma, or External, which means controlled primarily on another system, such as a Student Information System (SIS). Users have a unique ID. In our Network Zone (NZ), user IDs are unique across all institutions because we use unique prefixes to differentiate between schools with similar identifiers (e.g., George Washington and George Mason).
Alma user accounts are assigned roles or privileges, which allow users to access and use various functions within Alma. Typically, these roles are specific to the duties of each library staff member. Based upon these roles, Alma presents different pages and options to different users.
Users may be public, staff, or contact users. Note: Contact user records are used for vendor contacts in the Acquisitions module and are not relevant to this document. In our NZ, some libraries use only public user record types and some libraries use both public and staff user record types. As long as user records have staff roles, they could be considered a named user.Roles Required for User Management
For most user management tasks, you need the User Administrator and User Manager role. In order to run the Staff Login Report, you need the General System Administrator role. To run reports in Analytics, you need the Design Analytics role.
Recommendation: Named Users
Every Alma customer is allowed a certain number of Named Users, or users with staff roles, when they purchase Alma. If a library goes over their contractual allotment, it is necessary to reduce the number of named users in the system. Managing users with staff roles ensures compliance with Alma contract terms and helps maintain accurate staff access and system security.
Review & Cleanup Process
At least once per year, institutions should utilize the Staff Login Report and additional Analytics reports to deactivate and remove staff roles from accounts that are no longer needed.
Note: There are two ways to remove a user record in Alma from the list of Named Users:
-
Deactivate the user record
-
Remove staff roles from the user record
Do Not Deactivate, Edit, Delete or Purge:
-
Any users whose Primary Identifiers begin exl_ or rialto_ . These are Ex Libris staff accounts that should not be touched and do not count toward the total of Named Users.
-
The leganto_guest user as that user allows guest access to Leganto and cannot be deleted; it does not count as a Named User.
-
Any WRLC central staff users, as they do not count toward the contractual limits
Do Deactivate, Edit, and Purge:
-
Staff roles on student users accounts once they are no longer needed
-
Generic or internal accounts when no longer in use
-
User accounts created for setting up an integrated Ex Libris product such as Leganto, Rialto, Rapido, etc. (ex: a Leganto test user may have the “Course Reserves Manager” role)
Staff Roles Not Counted by Ex Libris
The following staff-related roles are not counted as “named users” for contractual purposes:
-
Patron
-
Trial Participant
-
Leganto-specific roles (Instructor, Leganto Course Operator, and Leganto Interface Administrator)
-
Rialto-specific roles (Selector, Selector Limited, Super Selector, Rialto Manager, and Rialto Administrator)
-
Ex Libris admin users
However, users who have additional roles in addition to excluded roles are still considered named users.
Maintaining Records of Staff Roles
Sometimes an institution will want to maintain a record of staff roles associated with a specific staff position, and the user remains active after leaving (such as retired faculty and staff). Institutions in this situation should consider creating a roles profile as an alternative.
Other Named User Account Considerations: Generic Accounts
Ex Libris currently recommends using generic accounts as a way to reduce named user accounts (see their Best Practice Toolkit), however, they also warn that the same generic account should not be used simultaneously by 2 or more users.
For additional context on this issue: when WRLC migrated to Alma in 2018, members were asked to report their total number of full‑time staff to Ex Libris to determine the Named User counts in the contract. Guidance on student staff accounts was limited, but Ex Libris strongly discouraged the use of generic shared logins for security and activity‑tracking reasons. While some WRLC libraries can use shared accounts for student workers, others cannot due to campus security policies.
Other Named User Account Considerations: Internal Accounts
Many institutions use internal accounts for users who cannot be added via SIS. For example, this may include community borrowers or visiting scholars. Some institutions may also use internal accounts for testing purposes. Those accounts should be deactivated when not in use.
One exception: Ex Libris recommends that institutions using single sign-on should consider having a back-up internal account that can be used to log in to Alma if your single sign-on authentication system goes down.
Recommendation: Deleting vs Purging User Accounts
When user accounts are deleted, all statistical data is deleted too. When user accounts are purged, statistical data is kept according to the Delete User Policy.
When removing user accounts of any type, always Purge them using either the Purge User Records function or the Purge Users job.