Alma
Your feedback matters to us. Help us improve Alma by telling us what you’d like to see using the message areas below. You can also can support something already posted.
We would love to be able to respond to every idea that is submitted, but this is not feasible. We are, however, committed to responding to the most popular ideas—those that have received the most points.
For more information please review our FAQ and guidelines. Thank you.
- or
No existing idea results
- ~ No ideas found ~
1744 results found
-
Overlap analysis report - add a column for local versus CZ
Sometimes we have local portfolios attached to CZ collections. In the output overlap analysis reports that include IZ titles, it would be helpful to have a column which indicated whether the analyzed portfolio is a local portfolio or a CZ portfolio.
3 votes -
Alma Fulfillment - field MARC 740 should be visible
While searching in ALMA Fulfillment, the MARC field 740 should be immediately visible in a dedicated panel, without having to scroll all the way down to the MARC view. This happens in Primo where you can see the several titles of each volume of a specific work. Some books have several volumes, and despite having a general, collective title, sometimes each volume has its own title (and authors, etc.). This information should be easily seen in the results without having to search through the MARC view. Yes, I know this information is searchable and can be retrieved, but for the sake of efficiency this field should be visible in a more pratical way.
While searching in ALMA Fulfillment, the MARC field 740 should be immediately visible in a dedicated panel, without having to scroll all the way down to the MARC view. This happens in Primo where you can see the several titles of each volume of a specific work. Some books have several volumes, and despite having a general, collective title, sometimes each volume has its own title (and authors, etc.). This information should be easily seen in the results without having to search through the MARC view. Yes, I know this information is searchable and can be retrieved, but for the…
2 votes -
Alma Fulfillment should have more facets
The Facets Menu in Alma Fulfillment (Patron Services) needs more facets, especially AUTHOR, COLLECTION/SERIES and PUBLISHER/EDITOR. Honestly, the few facets provided in the various search types are insufficient. These should be flexible configurable.
1 vote -
Allow CZ records to preserve or support local subject access for non-english indexing
We would like Alma to support a stable and sustainable solution for managing local subject access in Community Zone records.
Currently, when CZ records are updated, subject fields (65X) may be overwritten or removed. Although local fields can now be recovered in local indexes, this doesn't solve the core issue: subject access in our language is lost from the standard 65X fields, and this information becomes invisible to our consortial members.
We manage a large and continuously growing volume of electronic records, and the loss of controlled subject access has a significant impact. We have already identified more than 6.000 titles where subject headings that had previously been indexed were lost due to CZ updates. This number continues to grow over time.
We propose the following improvements:
Allow institutions to protect specific subject fields (e.g., 65X) in CZ-linked records from being overwritten by CZ updates.
Provide a supported mechanism to map local subject fields into standard 65X fields without those fields being lost during synchronization.This is not merely a local customization issue, it affects discovery quality and multilingual access. As electronic collections continue to grow, this limitation increasingly impacts metadata quality and user experience.
We believe Alma should support multilingual and locally controlled subject access in CZ workflows in a sustainable way, without forcing institutions to rely on workarounds or repeated data recovery processes.
Thank you for considering this enhancement.
We would like Alma to support a stable and sustainable solution for managing local subject access in Community Zone records.
Currently, when CZ records are updated, subject fields (65X) may be overwritten or removed. Although local fields can now be recovered in local indexes, this doesn't solve the core issue: subject access in our language is lost from the standard 65X fields, and this information becomes invisible to our consortial members.
We manage a large and continuously growing volume of electronic records, and the loss of controlled subject access has a significant impact. We have already identified more than 6.000…
104 votes -
Request to Enhance the Purchase Requests API
We would like to request several enhancements to the Purchase Requests API.
First, when sending a purchase request API call from the library website to Alma, we would like the API to allow submission of the request date or request month and to return responses that reflect this information.
Second, the Purchase Requests API currently returns a maximum of 100 records. We request that these returned records be sorted in descending order by request date.
Finally, we would like the maximum number of records returned by the Purchase Requests API to be increased from 100 to 500.
10 votes -
Add "Any" as selectable format for Resource Sharing requests
The Resource Sharing request form does not allow a blank default (at least for books).
And you cannot have different default values for Article and Book requests.Having the option "Any" available would give flexibility and allow to have no default value.
3 votes -
Alma - Standardize Cross-Field Validation Across Configuration Dialogs
Request:
Implement dynamic dependency handling within Alma "Add Row" dialog boxes to support Proactive Error Prevention.The interface should only present users with valid input field combinations, ensuring that logically impossible configurations cannot be constructed.
While this request originated from a ticket regarding the Exclude Process Types from Publishing dialog, it identifies a broader need for platform-wide consistency in how Alma handles field relationships.
Functional Gap:
Currently, the "Exclude Process Types from Publishing" dialog treats [Process Type] and [In Process Type] as independent fields.The Problem: Users can construct combinations that the system knows are invalid.
The Result: The user only discovers the error after attempting to save, leading to repetitive data entry and administrative frustration.
The Solution: The [In Process Type] field should be disabled or hidden unless [Process Type] is set to “In Process.”
Case for Consistency:
Development has noted that proactive validation in similar mapping tables (e.g., Exclude Libraries and Locations) was a specific implementation for Primo. However, from a user perspective, when dialog interactions vary unpredictably, it creates:- increased cognitive load on staff
- slower task execution
- training overhead
- avoidable support tickets and escalation
- reduced confidence in system predictability.
Standardizing cross-field validation across the platform would align the Publishing workflow with other high-functioning Alma areas, such as:
- Exclude Libraries and Locations from Available on Shelf Facet: Dropdown options change based on the selected Library.
- Restricted Search Groups: Parameters change based on the selected Name.
- Search Profiles: Scope fields appear/disappear based on Scope Type.
- Opening Hours: Available fields shift dynamically based on Record Type.
Validation should be applied consistently wherever field relationships exist across the platform.
Request:
Implement dynamic dependency handling within Alma "Add Row" dialog boxes to support Proactive Error Prevention.The interface should only present users with valid input field combinations, ensuring that logically impossible configurations cannot be constructed.
While this request originated from a ticket regarding the Exclude Process Types from Publishing dialog, it identifies a broader need for platform-wide consistency in how Alma handles field relationships.
Functional Gap:
Currently, the "Exclude Process Types from Publishing" dialog treats [Process Type] and [In Process Type] as independent fields.The Problem: Users can construct combinations that the system knows are invalid.
The Result: The user…
4 votes -
New Content
Add "V&P Online" collection to Alma, it's already in Serial Solutions.
Code 1.W
Last Full Update 04/16/2014
Last Partial Update 06/20/2024
Provider Vita e Pensiero
Titles 25
Titles are selectable No
Status Not Tracked
CDI
checkmark66% View coverage
Default URL http://www.vitaepensiero.it/riviste.html
Default Database Name V&P online3 votes -
acquisition vendor analytics expansion: all URLs
We would like to see more complete vendor information in Analytics in general, however this specific request is for inclusion of all URL types, along with both their description and note fields.
The use case is that we are hindered from fully using all the fields within Alma when we cannot run reports on that information in order to back it up. The backup is necessary due to the lack of an "are you sure" popup for the Delete action. Also, administrative and statistics login information needs to be available to all acquisitions and e-resources staff, however it needs to be backed up in case of accidental changes. And since vendors don't have a history tab, again, the alternative would be to run a regular report for backup purposes.
We would like to see more complete vendor information in Analytics in general, however this specific request is for inclusion of all URL types, along with both their description and note fields.
The use case is that we are hindered from fully using all the fields within Alma when we cannot run reports on that information in order to back it up. The backup is necessary due to the lack of an "are you sure" popup for the Delete action. Also, administrative and statistics login information needs to be available to all acquisitions and e-resources staff, however it needs to…
19 votes -
Persistent User Group Data in Borrowing Requests Subject Area
We would like to request that the Borrowing Requests subject area in Analytics captures and stores the patron's information (specifically the User Group) at the time of the transaction, rather than pulling the current status from the user record.
Currently, historical reports on borrowing requests reflect the requester's present-day group. If a student who made a request three years ago is now a staff member, or if their record has been deleted, the historical data is either overwritten or lost. This makes the data entirely out of context and renders historical analysis and longitudinal reporting impossible.
In the Fulfillment subject area, Alma already captures a snapshot of the user group at the time of the loan. We suggest implementing the same logic for Borrowing Requests to ensure data integrity. Relying on the current user group for past transactions is statistically invalid and prevents libraries from accurately tracking how different user segments have utilized resource sharing services over time.
We suggest adding a native field that records the "User Group at Request Time" to provide a reliable historical record that remains unchanged regardless of future updates to the user profile.
We would like to request that the Borrowing Requests subject area in Analytics captures and stores the patron's information (specifically the User Group) at the time of the transaction, rather than pulling the current status from the user record.
Currently, historical reports on borrowing requests reflect the requester's present-day group. If a student who made a request three years ago is now a staff member, or if their record has been deleted, the historical data is either overwritten or lost. This makes the data entirely out of context and renders historical analysis and longitudinal reporting impossible.
In the Fulfillment subject…
53 votes -
Shipping Cost Lender Rules - Partner Organization Type
It would be great if ‘Partner Organization Type’ could be added as a parameter in the ‘Shipping Cost – Lender Rules.’ This would allow us to set the Partner Organization Type for new partners instead of having to select each new partner individually.
5 votes -
Add a 'Save Workspace' Option in Alma?
I don't know about others, but I would like an Alma option to return to where I left off on logout, rather than having to burrow back in from the same landing page every time, in both Alma and Analytics.
This is minor friction, but after 8 years of this, I have to say it chafes.
2 votes -
AI Metadata Assistant
The AI Metadata Assistant is limited to processing four pages or four files per upload. Enabling batch uploading would better support larger metadata workflows.
1 vote -
Authority control for name-title access points: link bibliographic 1XX+240 to authority 1XX $t
In Alma, bibliographic records containing 1XX + 240 do not establish an effective authority link with the corresponding name-title authority record (1XX $t).
As a result, when the authorized access point for a name-title authority is updated (for example, a change in the title portion in 1XX $t), the update is not propagated to the linked bibliographic records. The 240 fields in affected bibliographic records remain unchanged and must be identified and edited manually.
This behavior results in:
· High manual maintenance effort
· Increased risk of inconsistencies between authority and bibliographic data
· Reduced effectiveness of authority control in Alma
Use Case A library maintains name-title authority records for works and expressions. When corrections are made, the cataloger updates the authorized access point in the authority record (field 1XX $t).
However, Alma does not automatically update the corresponding 240 fields in bibliographic records linked to that authority. The cataloger must therefore:
Manually search for all bibliographic records containing the affected name-title access point
Edit each 240 field individually to reflect the updated authorized form
In large catalogs, this process is time-consuming, error-prone, and difficult to control, especially when multiple bibliographic records are involved.
Expected Behavior Alma should support full authority control for name-title access points, including:
· Proper linking between bibliographic 1XX + 240 fields and the corresponding name-title authority record (1XX $t)
· Automatic propagation of authorized heading changes from authority records to all linked bibliographic records
Implementing this functionality would bring name-title authorities in line with other controlled headings in Alma and significantly improve cataloging efficiency and data consistency.
Example
Bib record 100 1#$aCervantes Saavedra, Miguel de, $d1547-1616. 240 10$aDon Quixot de la Mancha. $lCatalà 245 0 |a Historia del enginyós cavaller Don Quixot de la Manxa
Auth record 100 1_ |a Cervantes Saavedra, Miguel de, |d 1547-1616. |t Don Quijote de la Mancha. |l Català
If we modify the $t of this authority, for example by entering “Quijotte,” the Authorities job will search for and make changes only in the $t of the 700 fields, so the 240 of this bibliographic record will not be modified.
In Alma, bibliographic records containing 1XX + 240 do not establish an effective authority link with the corresponding name-title authority record (1XX $t).
As a result, when the authorized access point for a name-title authority is updated (for example, a change in the title portion in 1XX $t), the update is not propagated to the linked bibliographic records. The 240 fields in affected bibliographic records remain unchanged and must be identified and edited manually.
This behavior results in:
· High manual maintenance effort
· Increased risk of inconsistencies between authority and bibliographic data
· Reduced effectiveness of authority control in…
37 votes -
Create new reports for Authority management
National libraries and institutions managing controlled vocabularies require robust tools to ensure the integrity of their authority files. Current Alma functionality (Authority Control Task List) focuses primarily on the link between bibliographic and authority records. We propose a new set of dedicated Authority Management Reports to identify internal inconsistencies, errors, and redundancies within the authority files themselves.
Proposed Reports & Functionality
· Orphan Authority Records: Identifies authority records without any associated bibliographic records. Crucial for cleaning up legacy data or unused headings.
· MARC Encoding Errors: Detects structural errors within authority records (e.g., missing mandatory fields like 008, invalid indicators, or incorrect subfield usage).
· Duplicate Authority Records: Identifies records with identical authorized headings (1XX) to facilitate merging and maintain the "unique entry" principle.
· Close Matches / Fuzzy Logic: A report showing records with high similarity in the 1XX field (e.g., minor punctuation or spelling differences) to catch potential duplicates.
Justification for Development
· Data Quality: For National Bibliographic Agencies, the authority file is a product in itself. These reports are essential to ensure the data shared with other libraries is accurate.
· Workflow Efficiency: Currently, staff must create complex Analytics reports or use external tools to find these errors. Integrating this into the Authority Control Task List would streamline daily maintenance.
· Database Health: Removing orphans and merging duplicates reduces system noise and improves search precision for both catalogers and end-users.
National libraries and institutions managing controlled vocabularies require robust tools to ensure the integrity of their authority files. Current Alma functionality (Authority Control Task List) focuses primarily on the link between bibliographic and authority records. We propose a new set of dedicated Authority Management Reports to identify internal inconsistencies, errors, and redundancies within the authority files themselves.
Proposed Reports & Functionality
· Orphan Authority Records: Identifies authority records without any associated bibliographic records. Crucial for cleaning up legacy data or unused headings.
· MARC Encoding Errors: Detects structural errors within authority records (e.g., missing mandatory fields like 008, invalid indicators,…
36 votes -
Update All Relevant Indicators When Correcting Preferred Terms Linked via Cross-References
The recent enhancement to Preferred Term Correction correctly updates bibliographic headings when the preferred and non-preferred terms are in different authority fields (for example, 410 → 130), and changes the bibliographic field tag accordingly (e.g., 610 → 630).
However, the current implementation does not fully synchronize MARC indicators between authority and bibliographic records.The enhancement documentation states:
"When a bibliographic field is updated to an X30 field, the non-filing indicators in the bibliographic record will be adjusted based on the linked authority record. According to MARC21 standards, the 1st indicator of authority field 130 (Nonfiling characters) will be copied to the 2nd indicator of the X30 bibliographic field."
This is not accurate. In MARC21 authority format, the 1st indicator of field 130 is undefined (#), and the 2nd indicator represents the number of nonfiling characters.
Specifically:In cases involving authority field 130:
o MARC21 defines the 2nd indicator of authority field 130 as the number of nonfiling characters.
o In bibliographic X30 fields (130/630/730/830), the number of nonfiling characters is recorded in the 1st indicator.
o Therefore, the system should correctly transfer the nonfiling value from the 2nd indicator of authority field 130 to the 1st indicator of the corresponding bibliographic X30 field.
o In addition, the 2nd indicator of the bibliographic X30 field should not be modified as part of this process.In all other controlled access points (1XX, 6XX, 7XX, 8XX):
o Whenever a bibliographic heading is linked to an authority record, the 1st indicator of the bibliographic field should be automatically synchronized with the 1st indicator of the corresponding authority 1XX field.
o If indicators differ, they should be updated to ensure full consistency.
Without this synchronization, inconsistencies remain between authority data and bibliographic headings, generating additional manual maintenance and undermining the integrity of authority control.
Proposed Enhancement
Extend Preferred Term Correction to include automatic indicator alignment between authority records and all linked controlled bibliographic access points, in full compliance with MARC21 specifications.
The recent enhancement to Preferred Term Correction correctly updates bibliographic headings when the preferred and non-preferred terms are in different authority fields (for example, 410 → 130), and changes the bibliographic field tag accordingly (e.g., 610 → 630).
However, the current implementation does not fully synchronize MARC indicators between authority and bibliographic records.The enhancement documentation states:
"When a bibliographic field is updated to an X30 field, the non-filing indicators in the bibliographic record will be adjusted based on the linked authority record. According to MARC21 standards, the 1st indicator of authority field 130 (Nonfiling characters) will be copied to…54 votes -
Relationship designators should not be searched in Field 5XX, subfield $a
In Authorities, when relationship designators are used to specify relationships between agents in field 5XX, with subfield $i (relationship information), Alma searchs the relationship designators included in $i instead of searching the agent name included in subfield $a (personal names; corporate names, etc.). The subfield $i is not part of the name of the author or contributor, it is a separate element that denotes a relationship between agents. It is for this reason that we propose that names be indexed by the name included in subfield $a instead of subfield $i.
10 votes -
Community Zone Authorities vs Network Zone Authorities
When authority records are managed from a Network Zone (NZ) in a cooperative way—that is, when several institutions create and maintain authority records of different types (names, subjects, etc.)—it is confusing for catalogers when authorities from the Community Zone appear.
For this reason, we would like the possibility to choose from which zone we view authority records, mainly in these two screens:
• In Browse Authority Headings in the NZ, we would like to have different tabs to choose which zone we want to consult, the NZ or the CZ
• In Browse Authority Headings in any IZ of the Network, we currently have two tabs: Community and Institution; and, Commmunity and Network. We would like to have a new tab to consult authority records only from the NZ.When authority records are managed from a Network Zone (NZ) in a cooperative way—that is, when several institutions create and maintain authority records of different types (names, subjects, etc.)—it is confusing for catalogers when authorities from the Community Zone appear.
For this reason, we would like the possibility to choose from which zone we view authority records, mainly in these two screens:
• In Browse Authority Headings in the NZ, we would like to have different tabs to choose which zone we want to consult, the NZ or the CZ
• In Browse Authority Headings in any IZ of the…28 votes -
Add delivery option for Booking request
We currently allow faculty to request delivery for booked materials using the note field. This functionality is configured for visual materials requested by faculty to be shown in the classroom. The workflow produces hold notifications since the request form does not allow for delivery option which creates confusion with the patron. This improvement idea was previously submitted by another institution but closed during clean up. We would still find this improvement beneficial as the same issue recently came up, so I'm resubmitting.
1 vote -
Support file exchange via Odyssey
While we are able to send and receive files with other Alma, Rapido, and RapidILL libraries via RapidX, the resource sharing world is much larger than these three systems. While ExLibris talks about supporting interoperability, we are not yet able to receive files using the file sharing method dominant among our peers, even though its platform is open source. Odyssey is a major player in the library secure file exchange world, and while we stress to our partners that they need to send non-returnables to us via other methods, often folks forget, deliver via Odyssey, and assume the request is filled. As the borrowing library, we don’t notice these files haven’t come through until an unreasonable amount of time has passed and we check in with the other library. Meanwhile, our patrons could have had these files the whole time - and in some cases, by the time we catch it, it’s past the patron’s deadline. Please build in the ability to receive files via Odyssey when using ISO to communicate with other libraries through Alma Resource Sharing & Rapido
While we are able to send and receive files with other Alma, Rapido, and RapidILL libraries via RapidX, the resource sharing world is much larger than these three systems. While ExLibris talks about supporting interoperability, we are not yet able to receive files using the file sharing method dominant among our peers, even though its platform is open source. Odyssey is a major player in the library secure file exchange world, and while we stress to our partners that they need to send non-returnables to us via other methods, often folks forget, deliver via Odyssey, and assume the request is…
4 votes
- Don't see your idea?