User Management Basics (New UI)
1. User Management Basics
1.1 User Management
Notes:
Welcome to this session of the Alma Administration Fundamentals Training. During this session, we will focus on basic user management configuration options.
1.2 Agenda
Notes:
In this session, we’ll discuss the following topics:
· Account and record types
· Roles and scopes
· User groups and job categories
1.3 Account Type
Notes:
Account Type - which can be either Internal or External;
1.4 Record Type
Notes:
Record Type - can be Staff, Public or Contact
Roles and Scopes - are used determine the privileges of a particular user;
1.5 Job Category and User Group
Notes:
User Groups and Job Categories are used for further classifying patrons.
1.6 Account Type
Notes:
There are two basic user account types in Alma: Internal and External. Every user record is either one or the other.
1.7 Account Type
Notes:
Internal users are records that exist only in Alma. They are created manually by library staff and their management is entirely within the scope of the library. You can add and delete internal users from within Alma, as well as modify any field in the internal user’s record, including user name and password. Authentication of internal users is performed using the Alma internal database.
External users are users that 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 synchronized on a regular basis. It is possible to temporarily update an external user’s information manually in Alma, but these updates are overridden by the next synchronization with the user information system.
Authentication of external users is performed outside of Alma-for example, in LDAP
Internal users cannot be updated via an external system as are external users.
Most of your users should be external users: students, faculty, staff and sometimes alumni. Managing users externally reduces the maintenance burden on the library for those users. Changes to external user records - including updates to user name, password, contact information and expiration date - are entered in the external system and then synchronized with the corresponding records in Alma.
Of course, for users who do not have records in the external system - for example guests, community users, alumni - there is no alternative but to manage these users internally.
1.8 Account Type
Notes:
Internal users cannot be updated via an external system as are external users.
Most of your users should be external users: students, faculty, staff and sometimes alumni. Managing users externally reduces the maintenance burden on the library for those users. Changes to external user records - including updates to user name, password, contact information and expiration date - are entered in the external system and then synchronized with the corresponding records in Alma.
Of course, for users who do not have records in the external system - for example guests, community users, alumni - there is no alternative but to manage these users internally.
1.9 Authentication
Notes:
When an internal user logs-in to Alma, their user credentials are authenticated against Alma’s native user database. Whereas, when an external user logs-in to Alma, since their user credentials are not stored in Alma, Alma must be configured to authenticate the user against an external user database, such as LDAP.
When an internal user logs-in to Primo, Primo’s PDS (or patron directory service) must be configured to authenticate them against Alma. Whereas, when an external user logs-in to Primo, Primo’s PDS must be configured to authenticate them against an external user database, such as LDAP.
1.10 Implementation Suggestion
Notes:
When you receive your Alma environment with the test load of data, external authentication will not be set up. This means that any staff operators with external user records will not be able to login to Alma. To facilitate your initial work with Alma, we recommend that you convert your testing team’s group of migrated user records to internal. Doing so means that these users will be to login to Alma immediately and begin working.
For each relevant user record, click on the ‘Toggle Account Type’ button to convert the External record to an Internal record. Add a password and any applicable roles to the user.
At the point of cutover migration, theses users’ account types will be restored to External. All roles added during implementation will be preserved and any migrated patron activity will be associated with the record.
Note: for this procedure to be successful, it is essential that the user’s Primary Identifier not be modified.
1.11 Record Type
Notes:
Another parameter in the user record is the Record Type. For purposes of this discussion, there are two record types in Alma - Staff and Public.
1.12 Record Type
Notes:
You can filter the list of users in Alma according to record type.
There is no intrinsic difference in the functionality associated with staff and public users: users with a record type of Public may be assigned privileges that allow them to login to Alma and perform functions normally associated with library personnel. Similarly, users with a record type of Staff may have borrowing and requesting privileges normally associated with patrons.
1.13 Record Type
Notes:
To maintain the distinction between public and staff users who have external user accounts, you will need to maintain two distinct user import integrations. This is necessary since all users updated via a given user import profile receive the same record type, either public or staff, as configured in the profile.
Note that user records migrated from your legacy system receive a record type of Public.
1.14 Roles and Scopes
Notes:
A few words about user roles and scopes.
In Alma, a user’s ability to perform various functions depends on the roles assigned to that user. Only the General System Administrator role, for example, has privileges to configure external integration profiles; only the Circulation Desk Manager and Operator roles have privileges to check-out physical items to patrons; only the Invoice Manager and Operator roles have privileges to create invoices, etc. In addition, only users with the Patron role have privileges to borrow physical inventory.
In this screen shot, we see a list of roles that have been assigned to this user.
Most roles have a mandatory scope associated with them. The scope of a role determines whether the privileges associated with the role are valid for all libraries in the institution, or only for some libraries. A user with a Circulation Desk Operator role that has a scope of the Science Library will be able to check-out items to patrons at a specific circulation desk in the Science Library, but not in any other library. A user with a Patron role that has a scope of the Main Library will be able to borrow material owned by the Main Library, but not material owned by any other library. On the other hand, a user with a Patron role that has a scope of the institution would be able to borrow material owned by any library (assuming such material can be borrowed).
Scopes allow you to restrict staff privileges to a certain library or libraries. This is useful when assigning privileges to your staff operators.
1.15 Roles and Scopes
Notes:
Alma authorizes users with appropriate privileges in accordance with the roles that have been assigned to that user. Whether authentication takes place within Alma or within an external directory such as LDAP, authorization always occurs within Alma. This, in fact, is why even patrons logging-in to Primo, and users with an external account type, must have a user record within Alma.
1.16 User Groups and Job Categories
Notes:
User Group is a parameter in the user record. The user group parameter is the primary parameter for distinguishing your patron groups - faculty, staff, students, etc. The user group parameter is functionally mandatory in Alma: loan and request rules, patron limits, loan limits, lost loan rules and other functionality in Alma use the user group parameter.
Job Category is another parameter in the user record. The job category parameter is not functionally mandatory. It can be used to sub-divide your user groups. For example, a user with user group Staff might have a job category of Library; a user with user group faculty might have a job category of Law. Job categories can help you reduce the number of your user groups by allowing you to subdivide those user groups by job category. You can use the job category parameter in most of the same places as you can use the user group parameter. Fewer user groups make administration and maintenance of Alma easier. Using job categories as a secondary classification of your users can help you configure more granular rules when necessary.
1.17 Agenda
Notes:
In this session we discussed:
Account Type and the fact that it can be either Internal or External
Record Type, which can be either Staff or Public
Roles and Scopes to determine the privileges of a particular user
User Groups and Job Categories, two parameters used to classify different users according to their association with the library.
We also provided a recommendation for converting external user records for some staff operators to internal during implementation. This is done to avoid creation of duplicate records for a given user.
1.18 Thank you!
Notes:
Thanks for joining us. For more information visit the Ex Libris Knowledge Center.
1.19 About this Training
Notes:
1 (Slide Layer)
2 (Slide Layer)
3 (Slide Layer)
4 (Slide Layer)
Published by Articulate® Storyline www.articulate.com