Versions Compared

Old Version 52

changes.mady.by.user Julie Brannon

Saved on

compared with

New Version 53

changes.mady.by.user Julie Brannon

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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.)

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

ExLibris Webinars

ExLibris has a very active support system with frequent webinars to help customers become more efficient and familiar with Alma, Leganto and related workflows.

ExLibris's YouTube channel is here: https://www.youtube.com/@ExLibrisLtd

Some selected videos as a place to start:


Changes from Aleph to Alma

Note
titleThis list is not complete!

As project staff continue to learn more about Alma, we will begin listing information here about changes from Aleph to Alma that we think it is important for library staff to know. This list should not be considered a complete inventory of what will be different - just things that we think will be worthwhile to remember, especially in Spring '24.


General / System Changes

Key Differences between Aleph & Alma

Aleph

Alma

Desktop-based Software

Web-based platform

Keyboard-focused with some point and click

Mouse-focused with keyboard shortcuts

Made up of separate modules

Unified system

Location-based knowledge of information (what's in which module?)

Search-based discovery of information

Static software environment

  • Log out / time out after 60 minutes of non-use. Alma will give a warning message 60 seconds prior to timing you out. (link)
  • There is also a separate, configurable timeout specifically for the Patron Services page that defaults to two minutes before timing out that page. 

Two environments - Aleph production and Aleph development. 

We will have two web platforms - Alma Production and Alma Sandbox (premium). The premium sandbox will have a copy of our production data, refreshed by ExLibris twice a year.

Updated through software versions, with a long time between versions

Updated monthly with full release notes (Release notes page)

Aleph System Number

Alma system number (the MMSID)

Note: Robust search, internal links between related records, and the ability to save and export sets of records make it less necessary/useful to know the system number than it was in Aleph.

Users are granted permissions to do functions in an Aleph module.

  • Users are granted roles in Alma, that are Ex Libris-defined groups of privileges. We will assign roles to library staff.
  • Some roles also have an optional or required scope, that restricts the privilege to the institution, library, circulation desk or department.
  • Many administrator roles can be granted as read-only, allowing those users to see "under the hood" in Alma in ways that were not easy to do with Aleph.


Users

  • All users who need to be able to borrow books will have a special role of Patron. 
  • Open requests will not stop a user from being deleted like they do in Aleph. Open loans and unpaid fines will still stop a user deletion. If the user only has open requests, the user can be deleted and the request(s) will be cancelled.

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.

  • Alma offers the ability to "dispute" fines. If a fine is marked as disputed, it will not count towards blocking based on a fine amount, and it won't be considered as part of a patron's "active" fines. A disputed fine can then be waived, or restored and then charged/paid.

  • Fine exports will be scheduled and automated, with no manual option to delay sending the fine. E.g., in Aleph we run a report that marks the fine as "sent to bursar", and that's done manually at the discretion of the library. In Alma, that report will be scheduled and done automatically each week.

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.
  • Alma does not keep count of the number of times an item has been renewed. Instead, it maintains a "maximum renewal period". E.g., if the item loans for 28 days now and we allow it to be renewed two times, the maximum renewal period in Alma will be 84 days. 
  • Loan fixed due dates for graduate students and faculty will be managed through the library calendar, which is an additional layer than the Aleph workflow. Library  calendars will create an "event" for the fixed due date, and then the due date term of use policy will use the library calendar "event" to set the due date. 
  • If a patron cancels a recall, the initial due date will be re-instated for the recalled item, and the person who has the book will get a notice letting them know that the due date has been changed back.
  • Calendars have a different structure. There will be an institutional calendar that will have events and exceptions that each library will inherit. Then the library itself schedules opening hours. You define one set of standard hours - a set for each day - and then exceptions for hour changes. We will decide if we want to use events, as they are essentially just notifications for calendars within Alma. Exceptions are what they sound like - changes to a library's standard hours, either open or closed.
  • Items will get an automated process status whenever they are on loan - similar to what you would see when looking at a list of loans in Alma. The list of possible things that could appear is shown in the dropdown below

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.

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

General

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.  This is what we called a "budget" in Aleph.
  • 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, the order type is stored at the PO Line and there are 38 PO Line Type values available in Alma, where there were only 3 order types in Aleph (M, O, S).  The Alma PO Line Type merges order type with 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 and analysis of next steps on this crosswalk.

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

Order Data that won't migrate from Aleph to Alma:

  • 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.  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: an invoice header with associated invoice lines.  There are slight differences in the name and controlled vocabularies of two fields:

There aren't dedicated fields in Alma to capture the invoice barcode or instructions such as "Pay Immediately" or "Pickup check", so the ExLibris advisors recommend that we continue to code those instructions into the notes field as we currently do in Aleph.

The process of exporting "Ready to be paid" invoices to an external Accounts Payable system is described in detail on this page: Invoice Export.  Note:  In Aleph, we currently use several custom services to manage the invoice export to Duke AP.  An initial assessment of ExLibris' documentation indicates that there isn't a way to handle two aspects of our Aleph customization:

1) The invoice export job extracts all invoices that are ready for payment and there isn't a way to run it only for invoices from a specific library, as we do currently in our custom Aleph service.  We can indicate that the output be split by owner library, so we'll need to explore how this will impact workflows.

2) There isn't a way to run a preview of the invoice export before actually running it (that's also a custom service in Aleph).  The ExLibris team suggests the following:

"In Alma you can make sure invoices are ready for export by requiring either Invoice Review or Invoice Approval before they are flagged for export. You can configure rules for determining when Review and/or Approval are required to keep the process as strreamlined as possible. If you prefer, you should be able to reproduce the Alma workflow using Alma Analytics. You would then, however, need to use the API to mark the invoices as either Waiting for Payment or Closed depending on whether you plan on importing updated invoice payment statuses from finance system."  

Additionally, we are exploring how to indicate that an invoice fund whould be assigned a DKU company code in the feed to AP since this isn't something we can currently handle in the feed from Aleph.

Serial

Prediction patterns and predicted items can 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.


Electronic Resource Management (ERM)

Licenses

Alma includes functionality to manage e-resource licenses and we plan to migrate FOLIO Licenses to Alma.  There are Terms of Use values available out of the box and we can add new ones if needed. To learn more about Licenses in Alma, check out this short intro video: Licenses overview.  There are a few differences between FOLIO and Alma Licenses:

  • Alma offers a template feature for quick license creation based on a template.  Alma also offers a duplicate function (which is also available in FOLIO).
  • We can assign an Alma License directly to an e-resource in Inventory.  In FOLIO, this connection occurred via the Agreement and Duke has not yet created Agreement records in FOLIO.
  • We can assign an Alma License directly to a PO Line.  In FOLIO, this connection occurred via the Agreement and Duke has not yet created Agreement records in FOLIO.

Usage Reports (COUNTER via SUSHI)

Both FOLIO and Alma offer very similar functionality, though the user interface design is more tabular in Alma.  One key difference is that SUSHI credentials are managed on the vendor account in Alma, whereas in FOLIO they are managed on a separate eUsage provider record. Both systems support harvesting various COUNTER report types and uploading.


Analytics

Alma's reporting tool, "Analytics" provides out-of-the box reports and dashboards as well as powerful custom reporting and data visualization capabilities.  If your user account includes the "Design Analytics" role, you can access Analytics by signing into Alma and selecting Analytics from the left menu bar. 

Analytics data is updated every 24 hours from a snapshot of Alma data.

Helpful learning tools for Analytics: 

Troubleshooting tip for accessing Analytics: You need to be signed into Alma and your session needs to be active to successfully launch Analytics.  If your session hasn't been active in a while, you might bump into the Oracle login screen below.

To resolve this, follow these steps: 

  • Close the tab or window that displaying the Oracle login screen
  • Go back to your Alma tab & sign out of Alma by clicking on the person icon in your top right menu bar