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 ~
1773 results found
-
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…
40 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,…
39 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 -
Add GND to the Linked Open Data (LOD) editor, Alma Lookup Service
For now, the service only includes a few sources. We would like to add the GND vocabulary. This vocabulary is very important because a large number of libraries use it.
1 vote -
Flexible and normalized comparison of portfolio coverage dates in Overlap & Collection Analysis
Currently, Overlap & Collection Analysis compares portfolio coverage dates exactly as they appear in the portfolio coverage fields. As a result, equivalent coverage ranges are not always recognized as matches when the dates are recorded at different levels of detail or when some components are missing.
For example, coverage such as:
• 2.1.2016, Volume 1 Issue 1
and
• 2016, Volume 1 Issue 1
may represent the same start point, but the system treats them as different because one includes a full date while the other includes only a year.
In many knowledge bases and vendor data, coverage dates are inconsistently populated — sometimes year only, sometimes year and month, and sometimes full dates. This leads to inaccurate or misleading overlap results.
Proposed enhancement:
Enable configurable comparison granularity, allowing institutions to choose the precision used for matching, for example:
• Year only
• Year + month
• Full date (year + month + day)
This would allow comparisons to succeed even when some date components are not populated, and would let each library select the level of precision that best fits its collection analysis needs.
Expected benefit:
This will:
• Improve matching accuracy in overlap analysis
• Reduce false mismatches caused by different levels of date detail or missing components
• Provide more reliable overlap calculations across vendors and knowledge bases
• Support better collection management decisions (e.g., which collections to activate or deactivate)
• Minimize manual normalization and data cleanupCurrently, Overlap & Collection Analysis compares portfolio coverage dates exactly as they appear in the portfolio coverage fields. As a result, equivalent coverage ranges are not always recognized as matches when the dates are recorded at different levels of detail or when some components are missing.
For example, coverage such as:
• 2.1.2016, Volume 1 Issue 1
and
• 2016, Volume 1 Issue 1
may represent the same start point, but the system treats them as different because one includes a full date while the other includes only a year.
In many knowledge bases and vendor data, coverage dates are…120 votes -
Contribute URL Type (Override) to community-managed collections when contributing portfolio changes
I locally changed the Free E- journals link for bioRxiv (PID: 53441287610000041) to a dynamic URL:
IF(rft.doi)
https://doi.org/openurl?url_ver=Z39.88-2004&rft_id=info:doi/{rft.doi}
IF()
https://www.biorxiv.org/This allows the links on all the bioRxiv CDI records to go directly to the article. However, I can't contribute this change to the community because the "URL type (override)" won't go with it. So, my idea is to include that setting with any portfolio changes contributed via community-managed collections. This will allow the community to write more dynamic URLs and perhaps get those Free E- Journals links to link directly to articles, rather than to the journal's homepage.
3 votes -
Allow configuration of the default destination location for item move requests
Currently, when creating an item move request (temporary or permanent) in Alma, the Destination Location field is pre-populated with a default location. This default value cannot be changed or cleared by configuration.
We request an enhancement that would allow institutions to control this behavior - specifically, the option to leave the Destination Location field blank by default. This would require staff to actively select the appropriate destination location from the dropdown list, reducing the risk of accidental or incorrect moves.
This behavior would align item move requests more closely with patron physical requests, where required fields are not pre-filled and must be intentionally selected by staff.
Currently, when creating an item move request (temporary or permanent) in Alma, the Destination Location field is pre-populated with a default location. This default value cannot be changed or cleared by configuration.
We request an enhancement that would allow institutions to control this behavior - specifically, the option to leave the Destination Location field blank by default. This would require staff to actively select the appropriate destination location from the dropdown list, reducing the risk of accidental or incorrect moves.
This behavior would align item move requests more closely with patron physical requests, where required fields are not pre-filled and…
4 votes -
Add “Report to Ex Libris” Option to Failed Scheduled Alma Jobs
Scheduled Alma jobs that end with errors do not currently provide a built-in “Report to Ex Libris” option. Reporting such issues requires opening a support case manually and copying information from the job report.
Idea: Extend the existing “Report to Ex Libris” functionality (available at the portfolio level) to scheduled Alma job reports.
For scheduled jobs that end with Error or Failed status, allow users to open a reporting screen, pre-filled with the relevant job details (Job ID, process ID, error message).
Benefit: Provides a consistent reporting experience for recurring system jobs and improves accuracy of job-related support cases.155 votes -
Access host bibliographic record for "bound-with" relationships via API
Currently if you have two or more bibliographic records in a "bound-with" relationship via the 774 MARC field, the MARC data on the host bibliographic record contains the MMS ID of the child records, but there is no information on the child record to show the relationship. The Alma staff interface and the Primo interface clearly know that the relationship is there, because the holdings of the host bibliographic record are displayed in both interfaces. The information is clearly indexed, therefore, but is currently inaccessible to API users, limiting the ability to write scripts and interfaces that handle this concept.
The API should be improved to provide access to the linkage in both directions.
Currently if you have two or more bibliographic records in a "bound-with" relationship via the 774 MARC field, the MARC data on the host bibliographic record contains the MMS ID of the child records, but there is no information on the child record to show the relationship. The Alma staff interface and the Primo interface clearly know that the relationship is there, because the holdings of the host bibliographic record are displayed in both interfaces. The information is clearly indexed, therefore, but is currently inaccessible to API users, limiting the ability to write scripts and interfaces that handle this concept.
…
1 vote -
Allow relinking of items to other holdings records via API
The Alma user interface allows cataloguers to relink an item onto a different holdings record, either on the same bibliographic record or a different one. It is not possible to relink an item via the API.
If a library wishes to do a major restructure of holdings records via API (e.g. post migration from another system), it is currently impossible. For example, during migration of our early printed books from our old LMS, Ex Libris craeted one holdings record per location, despite there being multiple distinct items with different shelfmarks and provenance history, which should have separate holdings records. We have the skills to write a script to split these items across new separate holdings records, but the API does not exist to do this. Instead our script will have to delete and recreate items, which would lose the record history.
The Alma user interface allows cataloguers to relink an item onto a different holdings record, either on the same bibliographic record or a different one. It is not possible to relink an item via the API.
If a library wishes to do a major restructure of holdings records via API (e.g. post migration from another system), it is currently impossible. For example, during migration of our early printed books from our old LMS, Ex Libris craeted one holdings record per location, despite there being multiple distinct items with different shelfmarks and provenance history, which should have separate holdings records. We…
31 votes -
Add No Charge parameter to Update PO Lines Information job
Please add the No Charge field to the Update PO Lines Information job to allow a library to set the No Charge value on PO Lines in bulk. Currently, neither this job nor the Update PO Lines Information - Advanced job allow this value to be modified, though a user may modify the POL manually.
This is valuable to acquisitions staff that are cleaning up POLs for titles ordered in a subscription package, whether the POLs were migrated from a previous system or they were added to Alma incorrectly. Another POL will be used to encumber and invoice the subscription. However, since Alma does not allow a $0.00 price on a POL, these POLs tend to carry inappropriate $1.00 encumbrances which affect fund reporting. However, modifying the No Charge value hides the pricing and funding section of the POL and removes encumbrances.
In addition to adding this parameter to the Update PO Lines Information job, we request that it should also be valid to modify this value via the Acquisitions API without creating an error.
Please add the No Charge field to the Update PO Lines Information job to allow a library to set the No Charge value on PO Lines in bulk. Currently, neither this job nor the Update PO Lines Information - Advanced job allow this value to be modified, though a user may modify the POL manually.
This is valuable to acquisitions staff that are cleaning up POLs for titles ordered in a subscription package, whether the POLs were migrated from a previous system or they were added to Alma incorrectly. Another POL will be used to encumber and invoice the subscription.…
1 vote -
Supply more accurate cancellation reason when Requests – Handle Expiration Step automatically cancels booking requests
If a booking request releases its release time before staff have had a chance to pull the item, I believe Alma's default behavior is for the Requests – Handle Expiration job to assign Missing status and to send a FulCancelRequestLetter stating that the "Requested material could not be located". This causes patrons, who sometimes pick same day booking release dates, to think we've lost their requested items. A better cancellation reason would be BookingReleaseTimePassed/Booking request passed its release time.
3 votes -
Community Zone collection for University of Florida Press journals
Requesting a Community Zone collection for the journals published by University of Florida Press (UF Press) / University Press of Florida (UPF), as listed at https://floridapress.org/journals-home/.
1 vote
- Don't see your idea?