Getting to know Alma

Online Training Resources

Check out these online training videos from Ex Libris's Knowledge Center. (We will not be implementing Primo as a discovery layer, so you can ignore references to Primo in these videos.)

• Getting to know Alma: https://knowledge.exlibrisgroup.com/Alma/Training/Getting_To_Know_Alma/Getting_to_Know_Alma_-_English
• Alma Essentials: https://knowledge.exlibrisgroup.com/Alma/Training/AlmaEssentials
• Alma Webinars: https://knowledge.exlibrisgroup.com/Alma/Training/Webinars

We also have a growing list of resources being collated from other institutions that have gone live with Alma: Alma resources from other institutions

Changes from Aleph to Alma

Fulfillment

Course reserves

• Records for Faculty personal copies will be stored in Alma in their own library, rather than just in a reserves collection code. Alma will do it automatically when the personal copy record is created. There will be a location for each instructor that puts personal copies on reserve.

Fines

• If an item has associated overdue fines (even regular overdues), and the item then goes lost, Alma can either charge the overdue fine at the time it goes lost, or not charge the overdue fine, but the overdue fine will continue to accrue. There is no option to drop the overdue fine when the item ages to lost. It will have to be waived manually.

Loans

• We will be able to configure a "renewable" period - e.g., the number of days before a due date that a loan can actually be renewed.

Requests

• Alma will implement title-level requesting for all DUL libraries - title-level is the default behavior.
• We will have limited ability to restrict where requests can be picked up from. There are available control options, but they are not as expansive as with Aleph, and we need to explore what might work best.
  • We can completely prohibit the ability of a library to handle requests for another - e.g., Library A cannot handle requests for Library B. That would prevent patrons from asking for items from Library B to be requested for pickup at Library A. This would be done at the library configuration and would apply to all items in Library B. This could potentially allow a library to decide it does not want to deliver to a non-library-but-still-staffed pickup location if that was something that library wanted to do.
  • We can prohibit paging - e.g., requesting items from Library A for pickup at Library A - while allowing those items to be delivered to other libraries. (This is a use case for graduate student support at some libraries.)

Resource sharing

• When an item goes out on a lending request to another library, instead of having a "process" on the item, Alma will move it to a temporary location within the resource sharing library. 

Acquisitions

The Aleph "Ordering unit" doesn't exist in Alma.  Instead, acquisitions records are associated with an Alma "Library" which aligns more closely to the Aleph sublibrary, though the list of Alma Libraries likely won't include all of the sublibraries from Aleph. 

Vendors

• There aren't significant changes in how vendors are set up in Alma.  Some Aleph vendor fields won't migrate from Aleph. 
• To see more information about the data migration for Vendors see this Data Mapping Guide for Vendors which includes the list of fields that won't migrate.

Funds/Budgets

• Alma's fund structure differs from Aleph and includes new concepts: Ledgers and Summary Funds

• There are three types of Fund records in Alma:

  • Ledger(s): top-level record; you can have a single ledger for the entire campus, or separate out ledgers for schools or departments to mirror your actual financial structure
    • A Ledger in Alma represents a collection of Funds, while a Fund represents actual money in an account
    • A Ledger is a collection of Funds.
    • You can have a Ledger without a Fund but you can’t have a Fund without a Ledger.
  • Summary funds: used to group funds together for reporting purposes; if you are using a very simple fund structure, you do not need to have summary funds. 
    • A Summary Fund is not used for ordering or invoicing. Instead, a summary fund allows you to group similar allocated funds together so that you can track them more easily.
    • You cannot add money or perform transfers with a summary fund, and summary funds are optional
  • Allocated funds: these records have money associated with them, and are the funds used for placing orders and paying invoices
• The Aleph budget department code (containing the selector initials for DUL budgets) don’t migrate to a dedicated field in Alma, so we'll need to determine how to enable selectors to track spending for their budgets.

• Alma offers the ability to upload allocation amounts from a spreadsheet.

• To see more information about the data migration for Budgets, see this Data Mapping Guide for Budgets which includes the list of fields that won't migrate.

Orders

• Several key fields on the Aleph order are different in Alma.  For example, there isn't a direct parallel to the Aleph Order Type in Alma.  In Alma, they order type is stored at the PO Line and there are 38 PO Line Type values available in Alma since they fold in material type. Example Alma PO Line types are "Physical - One Time" or "Electronic Journal - Subscription."  We need to decide 1) which Alma PO Line Types we want to use and 2) how to populate the Alma PO Line Type on our Aleph migrated orders for each combination of Aleph Order Type and Order Material Type.  See Order Type and Order Material Type for the list of Alma values.
• Detailed info about these differences and the decisions we'll make about migrating order data at the links below which live in this Data Mapping Guide for Orders
  • Method of Acquisition
  • Order Type and Order Material Type
  • Order Status
  • Sublibrary
• Order log notes do not migrate from Aleph to Alma and these contain very useful historical information for acquisitions staff.  We will ask ExLibris whether it would be possible to migrate specific types of order log notes, as defined to move to FOLIO.  If this isn't possible, we'll likely need to store the notes in an external Library Data Service Center.  See Order Data that doesn't migrate to Alma for the list of order log notes that we'd like to migrate.
• Routing lists will not migrate from Aleph to Alma, but there does appear to be a routing list function in Alma. To see the full list of order fields that won't migrate, see this Data Mapping Guide for Orders

Invoices

The structure of invoices in Alma matches Aleph: and invoice header with associated invoice lines.  There are slight differences in 

• Aleph Invoice type maps to the Payment Method in Alma. The controlled vocabulary for Alma Payment methods is slightly different that what we using as Invoice Types in Aleph.  See Aleph Invoice Type to Alma Payment Method for analysis of that crosswalk for migrating invoices from Aleph to Alma.
• Aleph Invoice Payment Status maps to the Alma Payment Status. See Aleph Invoice Status to Alma Payment Status for more information about that crosswalk.
• Some Aleph invoice header and line fields won't migrate to Alma.  See Invoice fields that don't migrate to Alama for the full list.

Serials

• Prediction patterns and predicted items will migrate to Alma

Note: Item History data will not migrate to Alma from Aleph, so plans are underway to store that data in a Library Data Service Center outside of Alma.