We would like to propose the addition of the Library-only note field in Alma to the panel on the right side of the reading list page. We would like to propose a modification to the Library Type note in Alma to improve workflow efficiency. We would like this note to appear in the Reading List Information panel or the panel where the 'view in Leganto' link can be found, rather than in the Notes tab. This should be editable directly from the panel to allow Library staff to add comments or further information related to a list (e.g. summary of communication with tutors, details on item availability, etc.). It would be like the "receiving note" field in POLs, but for reading lists.

This change would streamline processes by making key information more visible and accessible, which would facilitate handovers and tracking of known issues.

The February 2025 Alma release introduced sound alerts for user blocks. It would be helpful for staff at the front desk to have similar alerts for pop-up messages related to fulfillment notes (from the item).

As an institution that is very enthusiastic about using the new Retention Information data fields for item records in Alma, we would like to request an enhancement that enables a user to assign multiple values to the Retention Reason field. For example, a single item could easily have all of the following statuses applied:

1. Institutional last copy

2. Faculty publication

3. Rare

4. Committed to some Shared Print program

5. Digitized material

Each of these retention reasons may correspond to different library staff workflow. For example, these retention reasons could support the following staff workflows, respectively:

1. Blocking withdrawal/weeding at the institutional (IZ) or consortial (NZ) level by collection development staff

2. Generate a report that can be used to populate a display shelf highlighting local research at our campus

3. Identification of materials that should be prioritized for preservation treatment

4. Block withdrawal/weeding and select for inclusion in data integration/sharing with partners

5. Identification of materials that are good candidates for off-site high density storage

Absent the ability to assign multiple values in a dropdown, which will provide a kind of authority control for approved statuses, we would be dependent on cramming all of this information into the free text Retention Note field. Obviously, this would be more error prone as it would require 100% consistency to achieve the same level of data reporting as the dropdown menu options would have. Additionally, parsing a free text field to find specific substrings in an Alma Analytics report is a much more sophisticated and therefore difficult task to accomplish. This would therefore have the effect of limiting the number of staff who are capable of effectively querying for all retention reasons.

There is a job to delete Fulltext objects from files, and there is a job to delete the files associated to representations (from a set of reps), but there is not a job to delete the digital files from a set of digital files. The Withdraw Digital representations removes ALL the files from a set of reps, but there may be cases where we want to delete only some/specific files from reps and not all of them.

You can release one record or all records from the MDE, but you can't release a selection of open records. It would be helpful if each record in the left pane had a check box to select and then release in batch.

Library staff must be able to record and expose how each resource is authenticated accurately.

ACCURATELY RECORDING how resources are authenticated:

1) default options in the Implemented Authorization Method are not customizable by us. We want to be able to control what shows in the dropdown and what order options appear. Currently, we must open a ticket with Ex Libris to do this.

2) default options in the Implemented Authorization Method do not encompass the categories we need. New authentication methods routinely come up. We would like to be able to add new categories as needed without having to ask Ex Libris to do so

EXPOSING how resources are authenticated:

--providing information to staff who troubleshoot end-user access problems: we cannot assess and correct problems if we do not know which authentication method is in use

--staff planning, we need to know what level of staffing and expertise is required and how it is changing. Seeing a snapshot of how many resources are used and which kinds of authentication will help this effort.

--technology planning: we need to be able to see trends for horizon planning. If a particular authentication method is becoming required by more vendors, we need to be able to plan for outreach, costs, and infrastructure)

Having the data and snapshots of what proportion of our resources use x, y, z authentication method would let us understand and target action if something changes related to a specific authentication method. For example, if the server that hosts ezproxy is getting upgraded, which resources are impacted? If the University adds or removes IP ranges which vendors do we have to contact?

Operators would benefit from not having to choose a Work Order Type and Status when the treatment is complete. It is not always easy to find out which cataloguing or repair operation has been carried out on an item. And above all, it's not useful if Done =“No” is selected.

Couldn't you put this last line at the beginning of the form, and open the Work Order Type and Status boxes only if "Yes" has been ticked, rather than the other way round?

Thank you and thank you for supporting this modest proposal.

Nicolas

When processing items from a cart, if they are scanned at "Return items" and the item is a "Ship physically" item, the new UI just brings up the item and in small letters says "Next Step - System" and the library it is to go to.

It also says "not on loan" (which in this case is not helpful, because there is an active request). The system "ships" the item, but Alma doesn't tell you that it did so and in order to print the shipping slip staff have to go back to the lending queue and find it.

We believe if Alma wants to help you and ship the item because there is a request, it should:

a) Indicate clearly that it shipped the item

b) Provide a quick way to print the shipping slip

c) Make that "Route to" next step message the primary/main pop-up so that the staff processing knows there is a request on it and routes it to the right place.

Currently staff are manually sending PDF versions of invoices to the external University payment system.

RIALTO should support sending of attached pdfs with invoices, as part of its automatic, integrated payment workflow.

Since the change to Alma's new visualization, when receiving the document from the order (POL) there are two behaviors that, in our opinion, are regressions:

- When we mark the check for “Keep in department” Cataloging copy, this check is not marked for future reception. We request that this check be kept marked by default.

- When the reception date has to be entered, marking a date before the current date on the calendar is not allowed.

What we are asking for is that, since this improvement that has been presented (display of all data integrated in the POL), when we mark the check for “Keep in the department” Copy cataloging, this check is left marked for a future reception. In addition, it is allowed to put a past reception date. These two features are allowed from Acquisitions > Receive and Invoice > Receive. However, they are not permitted since Alma's improvement of displaying everything integrated in the POL is the most useful, in our opinion.

In the overdue and lost loan profile settings, there is an option to create a block for all the overdue notification types. However, no such option is available for the change to lost profile type. If you set a block for an overdue item, then as soon as the item changes to 'lost' as part of this cycle, the block is removed automatically by the system which seems counter-intuitive.

As part of our workflow we apply a block for the last overdue notification we send at 21 days, which is then removed 7 days later by the system when the item becomes lost. Staff have to monitor overdues and then manually re-add it which is time-consuming.

And as it is a manual block, if the item is returned or replaced staff then have to manually remove, whereas a block created by the change to lost profile would automatically be removed when the item is returned etc.

Having similar options to the overdue notifications would mean we could have different levels of block depending on how overdue an item is with the severest set when the item becomes lost. Blocks used in this way also have the advantage of including blocks on requesting depending your block definition settings, which the loan limit blocks can't currently do.

It would be useful to make change to discovery import profile via API. For example, to make change Harvest start date and End date and run the job in all supported way (e.g. reload and delete). Currently there are some OAI resources that do not support harvesting deleted records and we had to do "reload and delete" manually and regularly.

Currently the data visualization do not support export as Excel or CSV function for those user that do not have Design analytic role. It would be much more useful to users if exporting Excel/CSV function is provided to a more general purpose report consumer.

If a library uses Alma's interested user functionality on purchase order lines, there is limited ability to remove that information, based on the parameter "po_line_remove_interested_users."

We propose improving the functionality by:

• Allowing libraries to have interested users removed even if they did not receive an Alma letter about the PO line;

• Allowing libraries to have interested users removed if their patron record has expired or been removed from Alma.

This would bring functionality closer to that of the request anonymization workflows that are managed in the Fulfillment anonymization workflow.

Collections that are open access display in search results with the Open Access indicator. The indicator is populated by the presence of 506 0_ $f Unrestricted online access $2 star in the record, but there is not an option to search by Open Access using this info. It would be very helpful to index and be able to search by this field for collection management.

The new feature to match imports against a specific collection is really useful. However, the use with delete files is limited because related records in other collection prevent deletion.

The import profile matches against the specific collection and delete records are imported. Good.
The import profile has permissions to delete records and inventory. Good.
The import refuses to delete record with related records. Bad. I've already specified I only want to manipulate records in the specific collection, so Alma should have permission to delete the one in the collection in this circumstance.

According to current Alma Analytics behavior, deleted courses and deleted reading lists are not retained in Analytics. (link)

This is contrary to the behavior of Alma in other areas, such as repository data, where deleted records are retained in Analytics. Their status is tracked as a "lifecycle" field.

Alma courses, reading lists and citation information should mirror this behavior for consistency and to ensure that a library can continue to report on the full scope of record usage.

Something that could be a useful bit of functionality for set management-- allow a user to favorite sets so that those particular sets are floated to the top of the list when choosing the "manage sets" function. This would make collaboration between Alma users easier, as you would not have to page through multiple pages of public sets to work on a long-term project.

Request:

Currently, a request confirmation letter is automatically emailed to patrons when they submit an interlibrary loan request. I would like to see the same—or a similar—confirmation letter generated and sent for internal book requests from our own shelves.

Providing this confirmation would:

• Acknowledge receipt of the patron’s internal request,

• Help manage patron expectations,

• And maintain consistency in communication across different types of requests.

This enhancement would improve the user experience and reduce the volume of follow-up inquiries.

Similar to fulfillment requests, such as loans, digitization requests, or holds, we would like to anonymize purchase requests (ideally as part of the fulfillment job).

There should be options of whether to include approved and/or rejected over a specific age. We understand there might be an issue with purchase requests that take an extended period to complete, so this requires purchase requests to be set to a 'closed' or 'completed' status when physical items are received or electronic inventory is activated. Currently, those statuses do not exist.

From a patron privacy perspective, separating the patron record from the content they are requesting has a significant benefit, particularly for active patrons researching potentially controversial subject areas. Keeping this information in the LSP is potentially hazardous since there is no job to delete purchase requests en masse, either via job or API call.

Currently for a general electronic service we can only create conditions based on metadata already contained in the given BIB record. Please provide a way to let the link resolver check any condition which is computable within a reasonable short amount of time!

Example Use Case:
Our library network offers a web service taking any given ISBN, ISSN or Union Catalog ID and returning 'true' if there is a BIB record for the corresponding resource in the union catalog and at least one of the network's libraries has an item of this resource available for ILL. Otherwise the web service returns 'false'. If we were able to let the Alma link resolver check a given ISBN, ISSN or Union Catalog ID against that web service we could offer an ILL service if and only if there is a pretty good chance that there is an item available via ILL.

Instead the only general electronic service we can offer currently is a context-insensitive "check whether ILL might be an option" link which resolves to our library network's SFX service menu(!) where an ILL service shows up if and only if there is a pretty good chance that there is an item available via ILL. (Yes, SFX is able to perform such "magic" thanks to so called "plugin thresholds". Their implementation in SFX as an arbitrary local script that evaluates the desired condition does not fit into a cloud environment, of course, but letting a web service evaluate the desired condition and return 'true' or 'false' does.)

Please note that this enhancment request has also been submitted as an idea on Idea Exchange: https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/49908636-allow-for-almost-arbitrary-conditions-in-general-e

We often have a set of portfolios that we know need the access type (either perpetual or current) updated, but right now there's no way to do a batch change on a set of portfolios. It would be very helpful to have the option to change that setting via a job.

The Duplicate Title Analysis output often marks things as duplicates in error b/c only the identifiers are used. There are many instances where identifiers are noted on versions of a record/item. Please incorporate/consider the edition and/or publication year, especially when running Detect duplication based on: ISBN.

BIB record has BCE dates (starting with '-') in the 264 and 046 fields, 008 position 6 is 'b'. However, the facets on the left side show years without '-' symbol, so it appears as CE dates in All Titles search results.

Why:

The publication year facet generated from field 264 includes the first 4 digits only (representing a year) and does not support special characters (such as -).

Hereby the request to enable the correct display of the BCE dates (from 264 $$c or 046).

We were working on our Work Order types and departments to get a better overview of items under repair and others in libraries. I can't figure out how the WO types are sorted in the fulfillment desks, they seem to be randomly placed when I add them!

The issue is about the sorting of work orders types in a circulation desk. I made video captures I can share if you like. As you can see on it I added 3 work orders type to a circ desk and I can't understand their sort in the circ desk parameters.
And I try another time, the sort will be different (start of the 2nd video).
And finally the Circ desk's Work orders types' sort will be the same for the librarians in the scan in menu : 2nd video.

The product Manager answered me, it's a bug and the Alma Tier2 Support Team said me "There is no Work Order Types sorting option. This was reported as a bug, but there are no plans of adding a sorting option for Work Order Types at the moment."

We would like to request the ability to customize the content displayed in the title section of the "Interested In" letter (label: Code – Title).

Currently, this section includes multiple bibliographic elements such as the title, author/creator, place of publication, publisher, publication date, and ISBN if available in the bibliographic record. While this level of detail may be useful in some contexts, it can make the letter appear cluttered and harder to read, particularly when fully cataloged records are imported into the system.

To improve clarity and readability for our clients, we would prefer to limit the title section to display only the title.

Attached is an example letter form our institution

Current Situation: In the History tab of a user record updated by the SIS feed, it is often unclear what specific changes have been made. The only visible change is the Status Date, even though the SIS feed indicates that a user record has been updated.

Proposed Enhancement: We request that the History tab in Alma be enhanced to display detailed information about all changes made to a user record by the SIS feed. This includes, but is not limited to, changes to user attributes, contact information, and other relevant fields. This enhancement will provide greater transparency and help library staff efficiently track and verify updates.

Justification:

• Improved Transparency: Clear visibility of all changes will help staff understand what has been updated, reducing confusion and potential errors.

• Efficiency: Staff will be able to quickly verify updates without needing to cross-reference multiple sources.

• Accountability: Detailed history logs will support better record-keeping and accountability for user data management.

Current Situation: When updating user profiles in Alma, each role's expiration date must be updated individually. This process is time-consuming and inefficient, especially when multiple roles need the same expiration date.

Proposed Enhancement: We request the addition of functionality that allows users to select multiple roles within a user profile and update their expiration dates simultaneously. This bulk update feature would streamline the process and improve efficiency.

Justification:

• Efficiency: Updating multiple roles at once will save time and reduce repetitive tasks for library staff.

• Consistency: Ensuring all roles have the same expiration date will minimize errors and maintain uniformity across user profiles.

• User Experience: Simplifying the update process will enhance overall user satisfaction and productivity.

Current Situation: Staff often encounter "System" changes in physical item histories, making it difficult to track the history of problematic items (e.g., incomplete or missing items). This lack of specific information hinders the ability to follow up with the responsible staff member.

Proposed Enhancement: We request that item histories in Alma include the Primary ID of the staff member who initiated any job that changes the location or bibliographic record of an item. This enhancement will provide greater clarity and accountability.

Justification:

• Improved Tracking: Including staff Primary IDs will help library staff accurately track changes and address issues with problematic items.

• Accountability: Staff will be able to follow up with the responsible individual, improving accountability and resolution of issues.

• Efficiency: Enhanced item histories will streamline the process of identifying and resolving problems, saving time and effort for library staff.

Current Situation: In Alma, when adding Statistical Categories to User Records, only the Description is displayed. This can be problematic as some Descriptions are identical, but their corresponding codes are different.

Proposed Enhancement: We request that both the code and the Description of Statistical Categories be displayed when adding categories manually and when viewing the User Record in the Statistics tab. This enhancement will provide clarity and prevent confusion.

Justification:

• Clarity: Displaying both the code and Description will help staff accurately identify and differentiate between Statistical Categories.

• Efficiency: Reducing confusion will streamline the process of adding and managing Statistical Categories.

• Accuracy: Ensuring that the correct categories are selected and applied will improve data integrity and record-keeping.

Current Situation: We are fully utilizing the User records' Statistical Categories in Alma, but there is no option to apply an expiration date to these categories. As users change between categories, it is important for statistical purposes to track when they were utilizing resources under a particular category. Currently, this process requires manual removal of categories, which is labor-intensive and impractical given our staffing constraints.

Proposed Enhancement: We request the addition of functionality that allows expiration dates to be set for Statistical Categories within User records. This feature would automate the process of updating categories, ensuring accurate and timely data for statistical analysis.

Justification:

• Efficiency: Automating the expiration of Statistical Categories will save significant time and reduce manual workload for staff.

• Accuracy: Ensuring that categories are updated accurately and promptly will improve the quality of statistical data.

• Resource Management: Better tracking of category usage over time will enhance our ability to manage and allocate resources effectively.

Current Situation: The current system for print periodical receiving in Alma involves predictions for each individual issue. This process is time-consuming and prone to errors, especially when dealing with delayed publications or changes in publication patterns.

Proposed Enhancement: We request a simplified system for print periodical receiving that uses modified Holdings rather than predictions. This enhancement would consolidate print periodical receiving into one area, reducing the number of steps in the process and making training easier. It would also allow students to take responsibility for some receiving tasks.

Issues Addressed:

• Efficiency: Predictions for each issue require individual updates if the publication is delayed, which is time-consuming.

• Complexity: Publications like newspapers can have hundreds of predictions, requiring navigation through multiple screens.

• Claims: Delayed publications result in unnecessary claims.

• Pattern Changes: Changes in publication patterns necessitate the removal of existing patterns and unreceived predictions, followed by the creation of new patterns.

Justification:

• Time Savings: A simplified system will make receiving faster and more efficient, saving time and reducing costly errors.

• Training: Easier training will enable students to assist with receiving tasks, improving workflow.

• Accuracy: Consolidating the process will reduce errors and improve the accuracy of received items.

Current Situation: When using the APIs to update user records in Alma, the entire User record must be extracted, even if only a small portion needs updating. This process is inefficient and results in the History tab indicating that the entire User record was updated, rather than just the specific field.

Proposed Enhancement: We request the ability to update User records via the API without needing to extract the entire record. Additionally, the History tab should accurately reflect which specific fields were updated, rather than indicating a full record update.

Justification:

• Efficiency: Updating only the necessary fields will save time and reduce the complexity of the process.

• Accuracy: Recording specific field updates in the History tab will provide clearer and more accurate tracking of changes.

• Resource Management: Streamlining the update process will improve overall system performance and resource utilization.

At present, the “Transaction note” field in Alma Fund transactions is not available in Alma Analytics. This field is the only place where staff can record details and justifications for fund adjustments (e.g., internal transfers, allocations, corrections).

Because it is not exposed in Analytics, libraries cannot report, audit, or review these transaction notes through analytics dashboards or exported data.

We request that the “Transaction note” field be added to Alma Analytics so that it can be used for financial tracking, auditing, and internal reporting.

We would like to suggest an optimization to the Analytics API or any part of the API that uses resumption tokens:

For these fetches, there is a resumption token in the returned response but it is within the body of the response. This means it's within a XML string returned that we then have to parse. So it adds an expensive XML parse to get at the token.

In our opinion this would be better off in a response header as it would allow one to easily access the token with the response itself. It could be in both to preserve current functionality too. This would allow us to write a cleaner way to handle it and should make these larger fetches a bit quicker.

Having the resumption token and isFinished in the response header allows one to use them direct from the response, e.g. pattern matching on the response object. So we can finish the API fetches independent of the XML unwrap (in theory a more time consuming operation). This should also allow to stream the body because you don't have to act upon it during the fetch phase.

The argument could be made from Ex Libris' POV that we're just passing the buck to the API to do the unwrap. Our thinking is chances are highly likely that when they build up the API response, they already have a token and isFinished variable instantiated to build the XML. So it shouldn't be an expensive operation to also append them to response headers.

Currently Alma does not have the functionality to distribute License Amendments to member institutions; it is only possible to distribute the Summary, License Terms, Notes and Attachments.

In a consortial environment, the ability to distribute centrally managed amendments is vital. Amendments often include changes to Terms of Use that must be communicated to member institutions.

Additionally, if the institution is displaying license terms in Primo VE, they need to have the option to display any terms that were updated in the amendment (either for all products in the agreement or for a specific product).

Currently, the only workaround is to add the amendment as a separate license, which is inefficient as well as confusing for member institutions.

We are considering this in light of enabling auto-renewals. It would be nice if instead of a set length for a renewal limit (e.g. 3 years) it would instead be 3 renewals. This would be easier to keep track of and would lead to more consistent due dates across the system.

In the Alma Monitor Requests & In Processes module, add the ability to filter requests for items that are currently On Loan.

When we relink inventory (holdings/portfolio/representation) from one MMS ID to another, we'd like to be asked if the citation can be relinked as well so it remains with the inventory and lives at the destination MMS ID.

This could happen on the confirmation screen. On that screen there is an area to select the destination bib record and an area to select Handling for bibliographic records without inventory. It would be nice for there to be another drop down to select Handling for records with citations. We'd like the options in drop down to include at least these three activities:

1. relink the citation to the same destination MMS ID as the inventory

2. remove the citation from the current record but do not relink it to the new record

2. do nothing with the citation (leave it on the current MMS ID).

Request: Add a field in the Portfolio fact table of the E-Inventory subject area titled "No. of Available Portfolios (CZ)." This field would store the number of available portfolios in the CZ for a given electronic collection. This field would allow institutions to use an Alma Analytics analysis to quickly identify which electronic collections in the IZ need manual intervention to bring them back in sync with the corresponding electronic collection in the CZ.

Reason for Request: By default, if an electronic collection is of type Aggregator package, our process is to set it to auto-activate new portfolios. Even with this setting, the electronic collections in the IZ fall out of sync with the CZ.

Impact of Problem: Considering the number of electronic collections that we have activated and the time that the current process requires, it is not feasible. As a result, our students miss out on access to paid resources that should be available in our IZ but are not; they also see resources that are no longer available and have been removed from the CZ but not the IZ.

Current Process: In order to identify electronic collections of Aggregator type that are out of sync between the IZ and the CZ, we must follow these steps in Alma:

1. Search for all electronic collections in the IZ

2. Apply the Aggregator package facet

3. Locate the first item in the list

4. Write down the number of available portfolios in the IZ

5. Click on the "Click to view the record in community" icon next to that electronic collection's name

6. Write down the number of available portfolios in the CZ

7. Click on the Institution tab to return to the filtered list

8. Move to the next electronic collection in the list

9. Repeat Steps 4-8 for all of the electronic collections in the list

Expected Outcome: An Alma Analytics analysis with the following fields and filters would allow for a quick comparison of portfolio numbers between the IZ and the CZ to determine which electronic collections need manual intervention.

• Fields

  • "E-Inventory"."Electronic Collection"."Electronic Collection Public Name"

  • "E-Inventory"."Electronic Collection"."Electronic Collection Id"

  • "E-Inventory"."Electronic Collection"."Electronic Collection Link Id"

  • "E-Inventory"."Portfolio"."No. of Available Portfolio"

  • "E-Inventory"."Portfolio"."No. of Available Portfolio (CZ)" *New field*

• Filters

  • "Electronic Collection"."Electronic Collection Lifecycle" <> 'Deleted' AND "Electronic Collection Type"."Electronic Collection Type (Description)" = 'Aggregator package' AND "Electronic Collection"."Electronic Collection Linked To CZ" = 'Yes'

Summary:
Library staff need a reliable method to identify which users (by User Group or Primary Identifier) are receiving email notifications from Alma. This visibility is critical for maintaining operational continuity during staff transitions and ensuring that notifications are reaching the appropriate personnel.

Problem Statement:
Currently, Alma does not provide a centralized or reportable way to view which staff members are receiving system-generated emails. This includes notifications related to jobs, tasks, errors, and scheduled reports. The lack of visibility creates challenges when staff roles change, as there is no easy way to audit or update notification recipients. A support case (#08075407) confirmed that this functionality is not currently available and recommended submitting an enhancement request.

Related Idea Exchange Post:
This request is similar to the Idea Exchange post “Ability to surface details of recipients/subscribers to Scheduled Analytics Reports”, but expands the scope to include all Alma-generated email notifications, not just those related to Analytics reports.

Proposed Solution:
Enhance Alma Analytics to include a new subject area or expand an existing one (e.g., System Events) to allow reporting on email notifications. Specifically:

• Subject Area: System Events

• New Folder: User Notification Events

• Event Type Filter: email

• Fields to Include:

  • Primary Identifier

  • Email Address

  • User Group

  • Notice Subject Line

  • Notice ID

  • Job ID (if applicable)

  • Date Sent

  • Error Status (if any)

Scope Limitation:
To ensure performance and feasibility, limit the reportable data to the last 30 days of email notifications.

Value to Library Staff:
This enhancement would allow administrators and managers to:

• Audit notification coverage across departments.

• Ensure critical alerts are not missed during staffing changes.

• Troubleshoot delivery issues more effectively.

• Maintain transparency and accountability in system communications.

We need a way to discontinue a standing order before completion and to inform the vendor about it via email directly from Alma.

"Cancel" does have the possibility to inform the vendor about the cancellation. However, by cancelling a POL, Alma is designed to completely undo the order by detaching already received items from the order and cancelling active requests on these items (this caused us huge trouble in the past, so we can’t use it).

"Close" is currently lacking the possibility to contact the vendor via email directly from Alma.

So we suggest that an option to contact the vendor via email, similar to the existing option of “Cancel”, is added to “Close”.

The Problem: Libraries send hundreds/thousands of notifications monthly (overdue notices, hold pickups, etc.) but have no way to track which letters are used most, how often they're sent, or their success rates. Alma has 150+ letters but Analytics only tracks a handful.

The Solution: Create a new Analytics subject area showing exactly how many of each letter type were sent, when, and whether delivery succeeded or failed.

Why Vote For This:

• Universal Need: Every Alma library uses letters - this helps ALL institutions

• Data-Driven Decisions: Prioritize customization efforts on high-volume letters

• Resource Optimization: Stop maintaining unused letters, focus on impactful ones

• Better Service: Identify and fix delivery problems faster

Bottom Line: Give libraries the basic usage data they need to manage their primary communication tools effectively.

When merging records through Alma’s Search Resources, make the existing Alma record the Primary and the incoming external record the Secondary.

Currently, when bringing in external records, Import and Integration Profiles treat the existing Alma record as Primary, but Search Resources makes the external record Primary. This inconsistency forces libraries to maintain two opposing sets of merge rules, depending on how the record enters Alma.

Making the Alma record Primary in Search Resources would align the behavior with other workflows. This could be configurable or at least opt-in so libraries can adjust their merge rule settings in the External Search Resources configuration to coincide with the change.

Benefits:

• Simplifies workflows by allowing a single set of merge rules.

• Reduces user confusion, since rule descriptions will match consistently across scenarios.

• Provides consistency in the Metadata Editor, where the record on the left will always be the Primary.

Make it possible for notes that staff add to patron/user accounts in Alma to be deleted in batch by running a job on a set created by an analytics report, or by using the following (ideally in combination) criteria:

• Primary Identifier of staff person who created the note

• Primary Identifier of user account note was added to

• Date range when notes were created

• Unique Identifier for note (this field doesn't exist currently)

• Note Type

This enhancement request relates to archived Alma Analytics enhancement request AENH-I-36286 which made it through the first round of voting in 2025 but ultimately was not accepted. We are aware of the new Cloud App "User Note Utility" however that app deletes all notes for a set of users. We need the ability to delete only specific notes added to user accounts.

The solution proposed by ExLibris developers during complexity pointing review was as follows:

The requirement seems to be:

• To be able to report on a list of notes based on the mentioned criteria

• To be able to delete the list of notes based on this criteria

An analytics based solution sounds like the best way forward. Would something like the below make sense ? -

Suggested solution -

1. Add the following fields to Note dimension in the User SA of Analytics -
   Note ID
   Creator
   Create Date
   Modify Date

2. Add a new utility of Delete Notes. The utility will use a UI for allowing to

• Select the Analytics Folder and the report name

OR

• Upload a file of note IDs.

The delete job will run on the list of notes and delete them, creating a report with failed note deletions.

Our Acquisitions Team would like: 1) the ability to see a renewal note to the renewals task list display. 2) a new status : "˜Renewed awaiting invoice"™. Frequently, we renew orders and then await the invoice. Having this dedicated status would allow us to monitor those renewals, similar to the function in one-time orders. It could be linked to the "˜amount paid in this current financial period"™. 3) to be able to sort the task list by renewal date without using the facets. Currently, the task list is sorted A-Z by default.

Our user accounts have a due date in the future that will encompass loans for the academic year. If a user separates from the university, their account will be set to expire by our user synchronization job. Their loans, however, continue to reflect the due date that was assigned when their account was active. This often results in items that are due many months after a person has left the university. Consequently, our staff must pursue updates to loans on expired account manually. We would like to see an option to update loan due dates when a user account is expired using a scheduled or run on demand job.

The Users subject area in Alma Analytics currently contains information about roles that are assigned to a user, but it does not contain the parameter information.

That means that you cannot report in Analytics on

• staff with a role and a specified circulation desk or department;

• staff with a role that is read-only;

This really limits the ability to monitor role changes and, in particular, to be aware of when an administrator role is actually granting access to an Alma user or simply letting them see existing settings. This needs to be added to Analytics.

(Also submitted in 2024, archived after not being accepted: AENH-I-36330)

This is from Ideas Exchange and was archived:

Allow for the updating of license terms using scripts or spreadsheets.

Currently all updating in licenses is a manual process. To add or reorder terms has to be done manually and to add a new term to existing license has to be done manually. Wouldn't it be nice for either type of updating to be achieved via a script or spreadsheet? For managing terms, it would be great to export the existing terms to a spreadsheet, make changes and then upload the new terms order and organization. It would also be great to be able to update existing terms in the same way, via either spreadsheets or scripts, whereby we could export the existing term fields (with presumably the identifier for each license), change the term data in the spreadsheet and then upload it back to Alma. It would also be useful functionality for folks who are new or just starting to work on their terms, to be able to work on the terms and order in a spreadsheet and then just upload it. It would also be nice to be able to write scripts that would say, change the language in every iteration of a particular term, if you wanted to – to standardize language or reflect a change in local policy.

It would be good to be able to search in the Alma ‘Users’ search index for the Letter’s name, e.g.

FulUserLoansCourtesyLetter - 11/03/2024 05:01:14 AEDT

The search would retrieve a list of users that have received the Letter you are searching for (then you can view the attachments in the Attachments tab to view a Letter example.

Impact of Problem:

Finding Letter samples can be tedious sometimes as some of them rarely get sent, and you might easily miss the narrow window of time in which an example is viewable in Letters Configuration.

Expected Outcome:

The ability to search in Alma’s Users search index for the name of the Letter (both basic search and Advanced search preferably).

Technical Requirements:

Include the Letter name from the Attachments tab as a searchable field in the Users search index. A new privilege could be created for this purpose that is limited to the User Manager or even User Administrator role in Alma.

Describe the functionality being requested:

We would like to be able to filter Courses by multiple Academic Departments simultaneously, both in the Courses advanced search, and within the Courses screen (in facets on the left-hand side).

Use Case

If we want to view all courses in the overall Discipline of Arts, we have to look at Arts department first, then Arts HDR department second, rather than being able to view all Arts courses at once. Similarly, we may want to get a single snapshot of a Faculty that consists of multiple disciplines – this isn’t possible currently in either the Courses screen or the Courses advanced search.

Technical Requirements:

• Add Academic Department as a search filter option in the advanced search for Courses.

• On the Courses page in Alma, allow the user to select multiple departments (e.g. Arts and Arts HDR, or all HDR departments, or all departments within a Faculty) at once.

Describe the functionality being requested:

Contact users in Alma become duplicated when they are listed in various areas of the vendor record, for example:

(See Word doc attachment for a screenshot that demonstrates excessive duplication)

Contact users should be treated more like actual patrons in terms of having their own unique record/ID in the system, and could be linked in various areas of the Vendor record using the same unique record.

Impact of Problem:

Duplicate records when you view Contacts make it quite an unwieldy area of User Management in Alma. We cannot merge these Contact users, so are stuck with in some cases a large list of duplicate Contact users.

Expected Outcome:

A single vendor contact record would be linked to various areas of the vendor record without duplicate contact records being created.

Describe the functionality being requested:

Please add two more Input Parameter options to the Role Assignment Rules (Automatic Role Assignment) table – User Campus and User Statistical Category.

Impact of Problem:

Currently we are not able to make use of RARs for anything but the most rudimentary rule (e.g. adding an instructor role for the Academic Staff user group, and adding the Patron role for all users). We are not able to identify library staff, nor staff on specific campuses, due to the limited options in the Automatic Role Assignment table. User roles are time consuming to maintain, and we have had to create a lot of Role Profiles due to the current RAR limitations.

Expected Outcome:

Example: A rule could be created for library staff on Sydney campus (identified by their Statistical Category for the Libraries department, and their User Affiliated Campus of Sydney) that automatically assigned them the Circulation Desk Operator Sydney role profile.

Describe the functionality being requested:

On the Courses page in Alma, the 'Unarchived' filter is applied by default. When subsequent filters are applied, the Unarchived filter gets removed. The Unarchived filter then needs to be re-added, which is an unnecessary additional click. Preferably the Unarchived filter would remain sticky when subsequent filtering actions are taken in the Courses screen. The ability to remove the Unarchived filter by clicking on the grey x should also remain for those who need to see archived courses for troubleshooting our maintenance purposes.

Use Case (see attachment for screenshots)

1. Staff member runs a search for courses by Searchable ID 2 value

2. The default list of results shows four unarchived Courses

3. After filtering this list by courses that have Reading Lists attached, the list expands to include archived Courses

4. The staff member must then re-click the Unarchived filter to get a list of current courses filtered by the “associated lists: exist” value.

Describe the functionality being requested:

When configuring libraries and viewing the list of physical locations, we would like to be able to see the External Name column on the main list of locations, instead of having to edit each location to see the External Name.

(See attachment for two screenshots)

Technical Requirements:

In Alma Configuration, add the External Name column to the display options in Physical Locations List, so that the column can be displayed or hidden within the cog menu.

Describe the functionality being requested:

General System Administrators in Alma should have the ability to hide libraries that are not in use by the institution but need to stay in Alma, for example the out of the box Resource Sharing Library, or libraries that have been created for various purposes but don’t need to function in Alma as libraries.

In the example screenshot (see attachment), the libraries indicated in red are not in use (the Resource Sharing Library not at all, and the other libraries not for anything other than facilitating Primo VE requesting). They must stay in Alma but are needlessly cluttering up Alma menus where they are not needed.

Technical Requirements:

Add a configuration option that allows libraries to be suppressed from display in the end user view of Alma. This configuration option should remove undesired libraries from such areas as search indexes, physical item drop down menus, and acquisitions-related drop-down menus (including Rialto menus). The configuration should be easily modified should certain libraries need to be re-added to front-end display in future. It should not affect display in Primo VE/NDE.

Description of problem:

When trying to troubleshoot a holdings record and figure out what was causing problems with its display, we had to keep going into configuration (Resources > General > Other Settings) to change the use_holdings_form parameter to false in order to view Marc in the MD editor, then return to configuration to change the parameter back to true to get the Holdings Form back.

Requested solution:

We want to be able to view the Marc for holdings records without having to change the use_holdings_form parameter back and forth in configuration. We want our staff to be able to continue to use the Holdings Form but for us, when troubleshooting, to be able to view the Marc display within the MD editor without having to go into configuration.

Description of problem:

Currently you have to go to either Primo VE, or Alma's “Create Purchase Request” page, in order to create a purchase request. We would like to have the option to create a purchase request from Alma title search results.

Use Case:

A staff member looks up a book to see if their library has it, but they find that another library has it while theirs doesn’t. They want to submit a purchase request (not an immediate order, e.g. if they are not allowed to place orders), but in order to do so they need to leave the page they’re on and to elsewhere to submit a request. Ideally they’d be able to choose “Create purchase request” from the actions menu and submit the request without having to leave their search results screen.

(See attached Word doc for screenshot)

At present, when an entry is created/added to Calendar Management in Alma for standard opening hours - no "valid from" or "valid to" field is available for the creator to assign/select. A "vaild from" date is automatically assigned as the date of creation of the entry with a "valid to" date being assigned 3 years in the future from the date of creation. By allowing customers to assign their own "valid from" and "valid to" dates this would accommodate sites with multiple opening hours that change, following a pattern throughout the academic year (e.g. term time, extended opening hours during exam times, summer times, etc.) without the need to edit each time these hours change.

This falls into the Fulfillment category (due to calendar management at the site level).

Communication from Alma to users is based on "preferred" type contact user information in user details. Should the incorrect "Addresses" or "Email Addresses" type be selected as the preferred option, this could lead to email communication and/or postal communication from being sent to the correct email and/or postal access. Of benefit would be the option to bulk update the addresses and email addresses type to preferred using the "Update/Notify Users" job in Alma.

Archived item from 2025 - AENH-I-36326

Add number of renewals against items in the loans table at Manage Patron Services screen. Currently additional clicks are required in order for Library staff to answer queries around the possible renewal of items due to local restrictions around the number of allowed renewals per loan.

Archived item from 2025 - AENH-I-36295

Patron loan limits are present in Alma at the Configuration end but are not visible in the Patron Services screen where it would add value to the existing information present on this page. Help Desk staff at our Institution do not possess the roles to switch to the Configuration screen to view such data. As we possess complex loan limits that vary according to user group and also within user groups, the addition of this information would allow us to provide a better user experience as this is one of our top user queries at our Help Desks.

Archived item from 2025 - AENH-I-36292

Current set up of Fulfillment in Alma does not allow for the due date to be set to a date and time in the past. This would prove invaluable during testing works.

Archived item from 2025 - AENH-I-36293

Alma has fairly well developed anonymization rules for loans, requests, fees/fines and borrowing request records, that allow libraries to control when records are anonymized, or not, based off of parameters such as location and user group.

However, the model breaks down for libraries who would like to offer individual borrowers control over whether their records are anonymized. For example, if a library does not generally anonymize loan records, and an individual patron wants their loans to be anonymized (as they have a legal right to do in many places,) libraries must use a workaround such as putting the patron into a specific user group and then anonymizing based off of that user group. That is a clumsy workaround path that is prone to error and takes up lots of staff time.

A more ideal way to do this would be to add in user statistical category as a parameter for fulfillment anonymization rules, in addition to user group. This mirrors the functionality of fulfillment unit rules.

Use cases:

• A library wants to anonymize all loans. A subset of patrons are graduate students working on research, and they want the library to maintain a record of the materials they've borrowed that they can reference. In this case, the default library rule could be to anonymize loans, but they could create a user statistical category of "Anonymization Opt-Out", apply it to appropriate patron records, and then write a rule so that those records are retained.
  
  

• Conversely, a library may not want to anonymize any transactions, but have a patron or set of patrons who request to have their records erased. The library could create a user statistical category of "Anonymization Opt-In" and apply it to the appropriate patron records so that those users could have their record information erased when their transactions are complete.

Adding this functionality would be extremely helpful in the loan, requests, and borrowing request fulfillment areas; less so in the fees/fines areas, but it could still be helpful there.

The Fulfillment Configuration Utility is a wonderful Alma feature for troubleshooting fulfillment rules and helping to answer patron questions. However, it is limited because the information it returns has to be generated manually, by searching for an individual patron and then an individual item, and reviewing the output in the UI.

It would be a huge improvement if there was an available API or APIs for the fulfillment configuration utility. Ideally, you would query an API or APIs with the user and item information, and it would return the attributes associated with the items for loan, request, booking, and overdue and lost loan profiles.

The use case for this is to allow a library to automate testing of their configurations. With APIs, a library could run, for example, a monthly audit of their fulfillment rules to produce a report that shows how item borrowing is working. This would allow staff to much more easily identify areas for improvement, especially if they are a newer Alma library.

Libraries that have multiple branches and/or multiple geographic areas are not able to effectively use Alma's personal delivery functionality because it does not provide enough control.

As currently implemented, if more than one library wants to provide personal delivery to their patrons, Alma chooses one circulation desk to route the item to. Once the item is received at the library that handles personal delivery, the item is immediately loaned to the patron, and then presumably enters a delivery pathway.

However, it is common for libraries to split up delivery work, especially for larger campuses with multiple libraries/branches, and to have specific types of patrons they are responsible for delivery to. This model does not work for those scenarios.

Use case:

• A Library system has a branch responsible for delivery to undergraduate faculty, and another branch responsible for delivery to Law faculty, since the law school is in a building several miles away. If a Law faculty member requests delivery of an item from the undergraduate library on the main campus, Alma knows as part of that request that the Law Library is responsible for delivery for that patron. It puts the item in transit to the law library, and then when the item arrives at the Law library, the remainder of the currently implemented delivery workflow kicks in.

We could imagine this control being seen in the Alma UI by adding a "Delivery Library" field to the user record, similar to the existing Resource Sharing Library and Purchase Request library fields.

This is a strongly needed API endpoint for borrowing requests to write integrations against systems from other vendors, particularly in Library Open Workflows.

Basically, we need the following:

1. be able to query requests in a particular state and for a particular partner within a specific IZ

2. be able to create/cancel/update requests (such as adding a remote record identifier to the request, add a label, or move to another status)

3. be able to 'send' the request to the partner from Alma upon save.

4. Update metadata within requests such as remote identifier,

it would be great if we might be able to send a request such as :

GET /almaws/v1/resource-sharing-requests?status=CREATED_BORROWING_REQUEST&&partner=PARTNER_CODE&limit=100

There are create and delete/cancel actions for resource-sharing requests, but not update functions (https://developers.exlibrisgroup.com/alma/apis/users/#Requests)

A script would perform remote record ID lookups automatically before sending to a specific network/partner using their local 001 identifiers to improve fill rates. Once the request was updated, a parameter in the GET request would be included to submit the request to the partner (submit_to_partner=true) and advance the request to "request sent to partner".

Ideally, we should be able to run a separate script to see if a particular RS transaction (based on the external identifier) submitted to a partner has gone 'end of rota', then update the alma resource sharing request by changing the status to "REJECTED_BY_PARTNER".

We LOVE the new ability for name/title headings to link when just the name portion matches an authority. It is invaluable and has reduced the amount of manual work needed for authority control. The current feature supports name/title partial linking for 100/110/111 and 700/710/711. Please expand the feature to include partial linking for 600/610/611 fields.

Having these 6XX fields linked to name headings will support the move to Open Linked Data and reduce the amount of manual work needed to maintain these headings.

Enable the "Circ Operator" role to Toggle an item to Missing status. Currently resides in roles with too much power to hand over to Circ desk attendants.

When using the Create Physical Items Work Order job, we would like to be able to assign work order statuses to items at the same time we create the work order.
Example use case: When our circulating laptops are returned, they are processed by IT before circulating again. We track them in IT using work orders, with statuses of Reimage or Repair showing where a laptop is and what processing it needs. If we use the Create Physical Items Work Order job to add work orders to a batch of laptops, it requires a second step after the work order is created to go in and alter the laptops to their current status. Making both of these steps available in the Create Physical Items Work Order job would greatly improve the efficiency of this batch process.
This request has also been posted by a different institution on the Idea Exchange: https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/15838135-expand-create-physical-items-work-order-job-to-i

It would be useful to identify items in a specific process/status step as well as process/work_order type. While I can write scripts against the step based on the expand_members option in my api output, I would like to be able to run jobs against a specific process step natively in Alma.

We need additional mapping options in Import Profiles. We need the ability to map to Electronic Collection, Material Type, and Acquisition method, based on field/subfield values in the input file. For example, because you cannot map to E-Collection, you have to have a separate profile for each collection for which you want to load portfolios. This dramatically increases the number of profiles we need to maintain. As another example, we have several EOD profiles for Casalini, when we could have 1 if Material Type and Acquisition Method could be mapped. We currently have multiple profiles because we load different material types (Books, DVDs, etc.) and have multiple Acq Methods, such as Approval, Purchase at Vendor System, etc.

The Scan in Items... Status field value is not sticky. This is a productivity issue and also leads to errors. The system always defaults to the first value in the list (alphabetically) and staff have to change it every time. The same is true for the Done option. The last used option should stick. Use Case: I am a staff member in Acquisitions technical services. I am an original cataloger and my workflow involves cataloging a piece, and then updating the status of the work order to "Shelf Prep." From the Metadata Editor, I complete my cataloging, save and release the bib record, then go to Scan In Items, change the status from the default value to "Shelf Prep," then Scan in the barcode. Now I work on my next bib record, finish cataloging in the MDE, save and release record, go to the Scan in Items screen, and now I have to re-select the status of "Shelf Prep" and scan in the item. I have to re-select this status all day as I go about my cataloging work.

Creating an order for a title which already has inventory requires too many steps, as well as too much navigation. For example, when placing a new continuous order for a physical title that already has a holding (such as when a vendor changes), an operator must perform 7 seven separate steps (below). This reduces productivity and requires too much mousing and clicking. We would like staff to be able to associate a POL with existing inventory directly from a POL via the ability to search and link a holding, item, or portfolio, as appropriate for the order type. 1) Create a POL using Assign Inventory Manually 2) Fill in the order details 3) Save 4) Navigate from the POL to the existing holding 5) Associate the holding with the POL 6) Navigate back to the POL 7) Use Save & Continue or Order Now

The Electronic Resource Activation Task List includes only $a of title field 245, which means important information is missing, specifically Name and Part ($n, $p). For example, the title "Oxford Bibliographies" appears 3 times in the list, when in fact the 3 titles are for these distinct works: Jewish Studies; Islamic Studies; Medieval Studies. The task list should include data from $a, $n, $p in the Title field because these are considered part of the title proper.

Switching frequently from one main circulation desk to other desks can lead to mistakes.

Associating each desk with a color theme could help prevent confusion for Alma users.

Our request is to allow color theme customization for circulation desks, in order to create a visual contrast bewteen desks. For instance :

Main circulation desk : purple theme

Reading room desk : pink theme

Etc.

Many libraries would like to have more flexibility when configuring pickup locations for requests, in a request terms of use.

One significant improvement would be to allow a library to specify, from the list of possible pickup locations, the specific pickup locations that should be allowed.

Alma campus functionality can support this need in a very limited way, but because a library can only be in one campus, it does not support most use cases.

This is functionality that was present in Aleph and is lost for libraries moving Aleph to Alma and is a major gap for libraries with multiple branches.

Use cases:

• Pickup location setup by patron group / statistical category - for example, a library may want to allow faculty and graduate students to request delivery to a particular research department where arrangements are made for a staff member to have Alma access and circulate books for those patrons. However, they don't want visiting scholars or community members to be able to have items sent to that research department. Right now, this use case can't be met in Alma. If we had a "pick from list of locations" option, we could write two request policies - one for faculty and graduate students that included the research department, and one for everyone else that did not include the research department. (Note that personal office delivery does not meet this requirement because not all users in this case would have offices.)
  
  

• Library / courier delivery - A set of libraries may want to deliver items to each other, but only allow reading rooms to deliver to a specified set of reading rooms at the other campus. This use case cannot be met with Alma's current configuration.

Alma roles need more improvement to enable libraries to follow the best practice of granting "least access" to IT systems, especially with regards to Alma Administration.

Put simply, Alma's administrator roles grant too much access by default to a particular subject area without giving the flexibility to better match permissions to a library's organizational structure.

This is particularly an issue for the role of Fulfillment Administrator.

Example scenario: Big University Library has a Discovery Department that manages Primo, and a Circulation Department that manages physical rules and copyright. In order for the Discovery Department to manage Primo and Summon, they must have the Fulfillment Administrator role to be able to configure Discovery Interface Display Logic; that gives them additional access to configurations that are not part of their job.

An additional consideration is that for many parts of Alma administration, configuration change history is not captured. This makes it more important to ensure that only the staff who should have access to fulfillment administration have that access.

One possible approach to this could be to keep the broad "Fulfillment Administrator" role but add new roles that provide access to specific segments of the configuration menu, e.g., "Fulfillment Administrator - Resource Sharing", "Fulfillment Administrator - Discovery Interface Display", and so on.

The recent work done to segment the Alma Analytics roles shows the usefulness of breaking roles apart to allow libraries to grant access appropriately; doing this for fulfillment administration is sorely needed.

The "Receive all" function does not account for multiple copies that come in different shipments/invoices. For example, if 3 copies of a title are ordered but only 2 copies come in, if we use the receive all function, it will receive all 3 copies. There is no popup window that will ask how many copies were received if multiple copies were ordered.

Make it possible to use regular expressions within indication rules in Alma.

Currently, if you run the manual job "Create Physical Item Move Requests", it puts the item in transit, but does not add the items to the "Pick From Shelf" list. Adding an optional checkbox to allow these items to be added to Pick From Shelf, would help in some scenarios when we are bulk moving items. If you want these items to appear on the Pick from Shelf list currently, the move request must be done manually on each item, which takes a lot of time.

Currently the Authentication Note field displays to everyone in Primo, which means anyone in the whole world can view the information in it, which renders it useless for sensitive information such as authentication information. Putting it behind the login wall would make it useful.

The ability to schedule manual jobs is a great enhancement, however the ability to edit the scheduled job rather than needing to delete and create a whole new one would be very much appreciated.

Fulfillment staff who are managing hold shelves often need to look at other aspects of the item or title record, to do things such as correct an item location or place a title hold for another interested patron.

Both the MMS ID and the item barcode can be displayed on the request record, but to look up the record, you have to copy/paste the information into search.

It would save time if either the barcode field could be a link to the item record, or the MMS ID field could be a link to open the title record.

Alma Reading Room functionality uses different states of a single loan record to track both items currently in active use by patrons in the library and items retained at the circulation desk for future use by patrons after the initial consultation, at which point the physical item request originally used to place the item on hold is closed out.
On-shelf, not-final reading room loans are not excluded from the Overdue notice that Alma sends on the same calendar date on which an item is due (cf. https://knowledge.exlibrisgroup.com/Alma/Knowledge_Articles/Overdue_notices_vs_Overdue_and_lost_loan_notification ) They are also included in the job for courtesy notices sent several days before items are due.
This creates a challenge for providing clear and coherent messaging to users of the service: patrons with an item 'on hold' by the mechanism of a not-final loan receive the same notice as users whose circulating books need to be renewed or returned. The same, succinct guidance can't cover both circulating items in patrons' possession and items which, by the nature of the service, are being retained by library staff for users.

Intuitively, the relevant message for users with these loans is that their 'holds' are expiring and will be reshelved, along with any guidance related to extending the hold. Unfortunately, the FulUserOverdueNoticeLetter template covers all of the user's loans in the IZ that have a due date on the same calendar date as the job.

In order for Alma messaging to meaningfully support the reading room service, a separate notice and associated job should be provided for Reading Room loans that are falling 'due' (i.e. expiring from the not-final shelf) and these loans should be excluded from the default Overdue notice job and the XML underlying its notices. ExLibris should also provide separate reminder notices for not-final Reading Room loans that will become 'due' in the next days, since again, any language crafted to advise and encourage desired user behavior in relation to returning borrowed items is going to be irrelevant at best for Reading Room users, and very likely confusing or even distressing. Reading room loans should also be excluded outright from the existing Overdue and Lost notice cycle.

Currently, the default check-in mode for reading room loans is 'final', with a radio button option to make returns not-final.

It's easy to correct a mistaken, non-final check-in with a second scan. There's no straightforward way to correct a 'final' check in performed by mistake, especially when this causes the item in question to go in-transit to a different library.

It doesn't appear that the radio button settings here persist even for an individual user across Alma sessions. Either non-final should be the default, or there should be an advanced fulfillment configuration option for setting the default.

It would be extremely useful to update values of license terms in batch, but currently, no such option exists. When we need to edit license terms for multiple licenses, we must do it one by one. It could become very time-consuming if something changes for the whole set of licenses or when we need to start filling the values up from scratch and already know some of them are the same for all/many licenses.

Sometimes, it’s also necessary to delete some term’s value from all licenses and then possibly enter other values, e.g. when we change internal workflows.

Examples: I need to set the “Remote Access” term to “Yes” for a set of licenses. I need to change the “Authorized User Definition” term from “text A” to “text B” for a set of licenses. I need to delete all values of the “Interlibrary loan note” term from a set of licenses.

Impact of Problem: When institutions need to fill in, update or delete license terms values for multiple licenses, the only way is to edit each license separately. It is very time-consuming and does not make sense in an automated system. We think this new feature would be helpful for all institutions using licenses – especially when they migrate to Alma and want to start managing their e-resources from the licensing perspective.

Expected Outcome: We imagine it would be similar to editing electronic portfolios. First, a set of licenses can be created (logical or itemized, including file import and preferably analytics import). Then, a new job exists in the “Run a Job” menu, e.g. “Change License Terms Information”. When I select the job and a set of licenses, license terms appear on the following page. I can check one or more terms and fill in the changes I want to make, including leaving the field blank to delete the particular value.

Locally created license terms should also appear here, and it would be more user-friendly if only the terms the institution uses are present (as configured in the “Manage License Terms” table) - I don’t have to scroll through such a long list. The editing options for individual terms should also correspond with the same table (Yes/No, select from a list, free text, etc.).

I can select when to apply changes for each row: unconditionally, if field empty, if field not empty.

Note: If there is another option to enable batch editing than sets and a job, we can use that as well, but it seems logical that the feature should be similar to other existing parts of Alma.

Although we can search and browse portfolios in many ways, Alma does not allow opening two portfolios simultaneously within the same session, which would be very helpful.

Example situations:

• I’m editing one portfolio and realize I need to check data in another one to keep values consistent.

• I need to copy text notes or coverage information from one portfolio into another.

• While activating a new portfolio, I need to compare its settings with an already activated portfolio.

• I want to keep one portfolio open for an extended period and temporarily open additional portfolios to copy or verify information.

Impact of Problem: Editing and activating portfolios often requires referencing multiple items. Since Alma only allows one portfolio page open at a time, users must repeatedly switch between search, result lists, and portfolio pages — each time losing the context of the previous portfolio. The lack of parallel portfolio view significantly slows down workflows, increases error risk, and makes complex portfolio management unnecessarily time-consuming. The impact is substantial for all institutions working intensively with electronic resources.

Expected Outcome: We would like Alma to support displaying two portfolios side by side within a single user session. Two user paths could be supported:

1. After performing a search or opening an electronic collection, users can select two portfolios from the list to open simultaneously.

2. While editing a portfolio, users can “hold” it open and temporarily return to search to find and open a second portfolio without losing the first one.

Each portfolio should appear in its own view pane or split-screen area. Users should be able to close either portfolio independently, keep one open while replacing the other with a new one, and continue editing without reloading or losing data.

Autoload collections are not always clearly identified in Alma. The default name of the collection does not always mention this information and there is no specific tag which can be searched or displayed in the CZ releases reports. This can be the source of useless changes by EIO or creation of cases.
We do not want to add terms like ‘AutoHoldings’ or ‘Autoload’ in the public name of the collection as this is not an useful information for end-users on Primo.It would thus be very useful to tag these collections with the mention ”Autoload” in the Alma collection search results, in the CZ releases reports and to allow the search on collections concerned by this functionality. This request is growing in importance as more and more publishers rely on this feature.

It would be very helpful to flag activated Alma collections when they are concerned by display logic rules.At the moment, there is no indication and activation changes may have some impact on the discovery and fulfillment level. It would be very useful for electronic operators to be directly alerted (for example with an icon at the collection level or a message alert in case of collection's deletion). It could prevent collection deletions or other mistakes made due to lack of knowledge.

When using the Community Zone Updates Task List, I find myself seeking the option to exclude certain Report Types or other filtered information.

For example, there is currently a way to view All Report Types, but if I want to exclude Portfolio Coverage Update from my search, there is no way to do that. Currently, I would have to check every single Report Type individually or sift through All.

I am proposing the addition of logical operations (such as AND, OR, NOT) to the filters of the Community Zone Updates Task List. In practice, this should help users be able to review what they need in the task list, as opposed to certain filters, or All.

As stated in the Alma Roadmap 2025-2026, "Analytics will support integrations with external data sources, allowing users to analyze data from multiple systems within the Analytics platform." (https://knowledge.exlibrisgroup.com/Alma/Product_Materials/010Roadmap/Alma_Roadmap_Highlights_(2025-2026)/Analytics_and_Insights#Integration_with_External_Data_Resources )
This new feature is expected to simplify workflows and save time by eliminating the need to access multiple systems, thereby improving staff efficiency and effectiveness.

It would be highly valuable if Primo Analytics Mixpanel data were considered a priority candidate for inclusion within this consolidation initiative.

It would be great to be able to select multiple different sets when you run a job. For example, running the Link to Network Zone job, and being able to select more than one set.

It would be great to have more parameters pulling from different aspects of the record in the All Title search. For example, adding certain POL information such as vendor account or vendor name. This would allow us to make more specific logical sets that we can run schedule jobs on.

We work closely with our Student Accessibility Support office with particular regard to our students with print disabilities. Students let that office know that they opt-in to disclosure of their name to the library, so when it comes to digital access rights, they have elevated permissions. This impacts any in-copyright materials that are digitized solely for accessibility as well as items we have in controlled digital lending.

To complement what we have done with regard to digitized materials in our catalog, we would also like to add a parameter to the copyright rules so when these patrons make chapter or article requests, they can also bypass the normal United States copyright rules as allowed under the Chafee Amendment (17 U.S. Code § 121) since they have a documented accessibility need. Since resource sharing staff do not have an easy mechanism to know which students have print disabilities, without such parameters in place these students are denied scans to which they are legally entitled and which they need for their education.

In certain circumstances, such as when working with renewals or overdue books, we are looking specifically for books with certain due dates. However, currently the system does not allow us to sort sets by due date, and this can make the requests we need to work on hard to find. Adding the ability to sort by due date will save staff time and frustration.

Occasionally, OpenURL can't locate an item, but items can be found in the CDI. I am requesting a change in the way the OpenURL resolver searches the CDI by title and authors for possible matches.

For example, ProQuest Dissertations & Theses is a collection with no portfolios that shows available content via the CDI. When attempting to resolve from another database with no full-text access, the resolver is unsuccessful because there are no portfolio matches from the collection.

An enhancement to include OpenURL resolving by data available in the CDI would be a welcome change.

Some resources require a unique identifier in their access URLs. Ex Libris has two existing methods for managing unique identifiers for linking: linking parameter fields in CZ-activated package type collections, level URL overrides for database type collections, and the Custom Linking for Central Index Databases Mapping Table which contains linking templates for a number of databases indexed in CDI. These methods are controlled by Ex Libris and cannot be set up by IZs or NZs. For example, we cannot add linking parameter fields to a CZ or local package collection if needed. This is particularly challenging for consortia managing eResources centrally in the NZ because unless there is an existing CZ package collection with linking parameters, we are unable to customize access URLs for each of our member institutions distributed collection.

Furthermore, database collections do not have linking parameters and the URL can only be customized using the level URL override. For consortia, the access URL cannot be customized for each member connected to the collection in the NZ.

We would like to have the ability to add linking parameter fields to package and database collections or the ability to configure custom level URLs in database collections for each group the collection is distributed to.

The use of demerits for late returns does not allow for a granular blocking of a specific material type when borrowing. As the configuration allows the selection of material type when creating the demerit points it would be useful if the material type could also be applied to the item that is to be loaned, therefore not preventing all items from being loaned, but allowing the specifying of type, e.g. laptop.

At present, items present on the Pick From Shelf list disappear from the list once items have been scanned at the desk and placed on the hold shelf or the request is cancelled. However it is difficult for desk staff to easily ascertain if a print out slip has been printed for each item listed. A "Request Printed" facet filter is present on this screen however the facets panel is often hidden - the addition of a "status" to this screen against each item listed would improve staff workflows. Here the status would appear as "printed" or "pending" against each item listed, similar to the Printouts Queue screen. Here there would be no need for staff to expand the facets panel to check "Request Printed" thus speeding up and simplifying workflows.