Page Comparison

Used for mapping existing loans, bookings, holds, reserves, fines, fees, and blocks in current system to patron data in Alma.

Mandatory. Choose an ID that is unique within your institution. According to Users in Alma: “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.”

UNIV ID

or

P BARCODE

TBD

Notify patrons using automated messages when requested items become available, items are overdue or if fines owed.

Mandatory

EMAIL

Institutional email is preferred for staff and students.

Core information

Mandatory

FIRST_NAME

Patron’s first name.

Core information

Mandatory

LAST_NAME

Patron’s last name.

Necessary for synchronization with SIS; keeps your patron file up-to-date

Export fines/fees/blocks to Bursar system;

This 3rd party integration allows Alma to retrieve relevant user information from the SIS, such as user names, passwords, and user identifiers.

UNIV ID

TBD

Example: LDAP, Single sign on. Provides access to electronic resources via Primo VE from both on and off campus;

User may use Primo VE to create bookings/holds/requests, etc., patrons store search results, history & favourites.

Must exist for all relevant users.

UNIV ID

If your SSO identity is used for SIS match, this field does not need to be duplicated.

SMS notification

Occasionally used to communicate with patrons.

Subject to institutional privacy rules.

PHONE

If using for SMS notifications, mobile phone number is required.

If using for communication purposes, libraries can work with individual registrar to determine best option.

Print mail notification

Subject to institutional privacy rules.

The address does not need to be added to the SIS load if a college does not have a use case for this information.

ADDRESS_LINE_1
ADDRESS_LINE_2
ADDRESS_LINE_3
ADDRESS_LINE_4
ADDRESS_LINE_5
ADDRESS_CITY
ADDRESS_STATE
ADDRESS_CODE
ADDRESS_COUNTRY

Patron physical address.

Analytics: such as programs/departments can be mapped in Alma;  Managing User Statistics allows reports to be filtered by users, by user group, category, and so forth.

No

USER_STAT_CATEGORY

(Items listed below are suggested labels to map to USER_STAT_CATEGORY fields.)

There are 10 user stat category fields that can be mapped.

Below are suggested field labels to be mapped to these categories:

PROGRAM

Program the student is currently enrolled in.

FACULTY

The faculty or school the program is affiliated with. (eg, Liberal Arts or Business)

DEPARTMENT

Department where faculty teach or staff are employed.

Tagging records for patron file clean-up.

No

EXPIRY_DATE

For students end of current semester or academic year.

For staff and faculty, the college can determine the length of time. Greater than 5 years is a suggested recommendation currently.

The date on which the user will be purged. See Purging Users.

No

PURGE_DATE

2 calendar years after expiry date.

Provide alternate login for users, e.g., community users who are not included in your SIS integration.

No

TBDNot used beyond migration.

Map to the barcode information in your existing ILS.

This field will be a unique identifier and is typically consistent across all user types.

Barcode is also a common method used in libraries to complete circulation transactions therefore, it is reliable for linking patron data with circulation data.

However, some colleges may find that a username is a more consistent and reliable piece of information.

User’s title in current ILS, SIS and HRIS systems.

Mr, Ms, Dr for example.

Some colleges have EDI policies that advise the removal of gendered language unless necessary.

Your library may choose to include or exclude this data in future SIS loads based on internal business needs.

If your library is reviewing whether to remove gender identifying data in the future, you may choose not to migrate this field with your existing data.

The same considerations can be made for patron gender information.

Privilege expiry date in existing ILS.

Colleges can determine expiry dates and purge dates within Alma.

Expiry dates can be unique for to each library based on internal business needs.

While expiry dates can be determined at the institutions, standardized purge policies may be suggested to the Steering Committee to ensure patron database limit compliance.

Used for mapping users during migration.

Map users that are delivered in current SIS loads to EXTERNAL.

Map users that are created manually in the current ILS to INTERNAL.

Users created within Alma are considered internal because they are created and managed within Alma.

Users created and updated using the SIS load are considered external because account management occurs outside of Alma. The external system that manages incoming patron accounts is considered the parent system, while Alma is the child.

N/A

Used for mapping existing loans, bookings, holds, reserves, fines, fees, and blocks in current system to patron data in Alma.

Not used beyond migration.

Map to the barcode information in your existing ILS.

This field will be a unique identifier and is typically consistent across all user types.

Barcode is also a common method used in libraries to complete circulation transactions therefore, is is reliable for linking patron data with circulation data.

Map any existing identifiers in current ILS to the UNIV_ID or barcode field.

There is information on the Symphony to Alma Data Delivery and Migration Guide to help Symphony colleges migrate identifiers.

If your library chooses to migrate previous IDs and Inactive IDs from Symphony, make sure that you consider which identifiers will be included in the SIS integration. You will may need to reserve identifier fields for SIS and SSO matches.

Alma requires the following for each patron record.

Primary ID - must be unique to each user

SIS match - must exist within SIS if you plan to update your patron files using a fresh load from your student information system on a regular basis.

Authentication match - must exist within SSO

If these values are the same, your library may only need a single identifier. If they are not the same, you can have up to 4 additional identifiers.

Eg, if your college uses the student email as the SSO identity, the SIS match, is unique for each user and is represented by a barcode on your student card, no other identifiers are needed.

The identifiers can be locally configured at each institution.

The network zone uses linked accounts to perform fulfillment activities within the network zone. This eliminates the need for standardization across the network.

As long as each value exists within the record, it does not matter which field they occupy. It only matters that you identify which will be the Primary ID.

If colleges are receiving this data currently, it exists in the “User Cat” fields in Symphony and elsewhere in other ILS systems.

This data will be migrated to the USER_STAT_CATEGORY fields in Alma.

If you do not currently receive this information, your college may want to discuss which fields are relevant for statistical reporting when configuring the SIS integration.

There are 10 available fields for user statistical data.

Many colleges already receive statistical data in their SIS load or through other methods.

For data that is common across the network standardization is recommended. Shared field names will support consistent reporting of statistical data.

Some colleges may not receive all fields listed below. For data that is present, the following field names are recommended:

PROGRAM - Student’s current program affiliation.

FACULTY - Faculty or school responsible for delivering programs to students (eg Liberal Arts and Science or Business).

DEPARTMENT - Staff or faculty department affiliation.

Email is one of the mandatory fields within the patron account.

If email is also used for SSO or SIS integrations, Ex Libris can configure systems so that email does not need to be duplicated.

Core information

Mandatory

Core information

Mandatory