52 results found

1. Please add the feature „Chat between Institution Zones“ to the Metadata Editor

   Ex Libris should offer the option of creating a chat for each data record. This feature would facilitate communication between individual libraries regarding incorrect data records.
   Currently, communication concerning bibliographic records are sent by email via a mailing list. For a library that has many departments with numerous employees, it is difficult to develop a workflow for jointly processing these emails. In a chat, several people within an institution can communicate with each other without having to coordinate internally beforehand.
   But smaller libraries would also benefit from this chat function. When several emails are sent back and forth on a topic, it quickly becomes confusing.
   It is also more efficient and clearer if the communication about a data record can be found next to the data record itself.
   One way to integrate a chat function into individual records would be to add a “Chat between Institution Zones“ button to each record in the search view and/or in the Metadata Editor (see image Alma Chat 1.1 and Alma Chat 1.2).
   An editor should then open (a big window unlike the small window provided by the „Add Note“ option“), in which the written exchange between the libraries concerned can take place. One library sends a request to the other libraries, and the other libraries respond to it. The last library to respond, or the library that makes the final adjustments to the record, should change the status of the chat from “open” to “closed” This requires a drop-down menu within the chat editor (see image Alma Chat 2 + 3).
   All chats with the status „open“ in every Institution Zone should be searchable using the advanced search (see image Alma Chat 4). Chats with the status „closed“ could still be searched using the title or ID of the record via the simple search.

   Ex Libris should offer the option of creating a chat for each data record. This feature would facilitate communication between individual libraries regarding incorrect data records.
   Currently, communication concerning bibliographic records are sent by email via a mailing list. For a library that has many departments with numerous employees, it is difficult to develop a workflow for jointly processing these emails. In a chat, several people within an institution can communicate with each other without having to coordinate internally beforehand.
   But smaller libraries would also benefit from this chat function. When several emails are sent back and forth on a… more

   •  

   •  

   376 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   20 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   AdminErez Shabo (Product Manager, Ex Libris) responded

   Could you please clarify whether this request refers to communication between consortia (Network Zone) members regarding their shared data?

2. 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… more

   107 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Incorporation of All Indigenous Syllabics from the Canadian Aboriginal Syllabics Unicode Block (Revisited)

   A previous enhancement request (March 2019; now closed) states that "not all Indigenous syllabics render in Alma, and thus, do not render in Primo either. As an important aspect of Canadian Libraries' commitments to Truth and Reconciliation, and as it is UN's International Year of Indigenous Languages, it would be excellent if Ex Libris could prioritize resolving this issue so that we can allow Indigenous users full discoverability of resources in their own languages."

   We have tested the whole range of Canadian Aboriginal Syllabics in our Alma/Primo and can report the following results:

   Unified Canadian Aboriginal Syllabics (Range: 1400–167F)
   **ALL of these characters work except ᒥ (14A5); this character was subsequently enabled in our Alma by ExL Support.

   Unified Canadian Aboriginal Syllabics Extended (Range: 18B0–18FF)
   **ALL of these characters work in our Alma/Primo.

   Unified Canadian Aboriginal Syllabics Extended-A (Range: 11AB0–11ABF)
   **NONE of these characters work in our Alma/Primo.

   Perhaps this idea is now defined narrowly enough for further consideration.

   Regards,
   Stefan Hintersteininger
   Simon Fraser University Library

   A previous enhancement request (March 2019; now closed) states that "not all Indigenous syllabics render in Alma, and thus, do not render in Primo either. As an important aspect of Canadian Libraries' commitments to Truth and Reconciliation, and as it is UN's International Year of Indigenous Languages, it would be excellent if Ex Libris could prioritize resolving this issue so that we can allow Indigenous users full discoverability of resources in their own languages."

   We have tested the whole range of Canadian Aboriginal Syllabics in our Alma/Primo and can report the following results:

   Unified Canadian Aboriginal Syllabics (Range: 1400–167F)
   **ALL… more

   61 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Request for a List of Selectable Special Characters in the MDE Virtual Keyboard

   Request regarding the MDE virtual keyboard for inserting special characters, which became available with the August 2025 release.
   I would like to be able to view all available characters at once, or to change the order of the character code blocks in the drop-down menu.
   It would be especially helpful if the characters could be displayed in Unicode order.
   Currently, characters are grouped and selectable via a drop-down menu, but this structure requires users to know which set contains the character they want to input.
   This makes the process inconvenient, especially when searching for less common characters.

   143 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   6 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

5. Linked Data Enrichment Moves $e Relator Subfields to Incorrect Positions When Saving Authorities with F3

   When saving a name authority record in Alma using the F3 function, the Linked Data Enrichment process is causing the $e relator subfield to move to an incorrect position within the field. Instead of maintaining the expected order (e.g., $a, $e, $1), the $e subfield is often placed at the end or in another unexpected location after $0/$1 subfields are added. This disrupts the intended structure of the authority field and creates extra manual work for cataloguers.

   Attempts to correct the placement by copying and pasting the $e subfield do not work as expected—Alma consistently pastes it at the end of the field, regardless of cursor position. This issue only occurs after Linked Data Enrichment and does not affect other fields or occur before enrichment.

   Ex Libris support has indicated that this is currently by design, as part of the Preferred Term Correction (PTC) process.

   Impact:
   • Authority records are not formatted as cataloguers expect, leading to confusion and extra manual editing.
   • The copy-paste function does not work reliably for $e subfields after enrichment.
   • The current behaviour reduces efficiency and increases the risk of errors in authority data.

   Request:
   Please review and enhance the Linked Data Enrichment and F3 saving process so that $e relator subfields retain their correct position (immediately after $a) when new $0/$1 subfields are added. Additionally, ensure that copy-pasting subfields works as expected in all scenarios. This change would improve cataloguing accuracy and workflow efficiency.

   When saving a name authority record in Alma using the F3 function, the Linked Data Enrichment process is causing the $e relator subfield to move to an incorrect position within the field. Instead of maintaining the expected order (e.g., $a, $e, $1), the $e subfield is often placed at the end or in another unexpected location after $0/$1 subfields are added. This disrupts the intended structure of the authority field and creates extra manual work for cataloguers.

   Attempts to correct the placement by copying and pasting the $e subfield do not work as expected—Alma consistently pastes it at the end… more

   80 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   2 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   AdminErez Shabo (Product Manager, Ex Libris) responded

   Can you please confirm whether the $e subfield is always expected to appear before $0 and $1 in your workflows? If this is consistently the case, it may be possible to address the issue using an XSL normalization rule to automatically position the $e subfield before these subfields.

6. Allow All MARC21 Fields Valid for Subfield $5 to be Saved as Alma "Local Extensions"

   The Problem:
   Alma’s current "Local Extension" model restricts local data to a hardcoded subset of tags (09X, 59X, 69X, etc.). This forces libraries to choose between keeping standard local data in the Network Zone (where it risks being overwritten) or moving it to non-standard local tags.

   When standard data (like a 700 donor name or a 655 local genre heading) is forced into a 9XX or 69X field, it breaks standard Primo indexing. We lose the ability to have this critical local data indexed in standard Primo indexes.

   The Solution:
   Update the Alma Metadata Editor and bibliographic validation rules to allow any valid MARC21 field that supports Subfield $5 (per LC/OCLC standards) to be saved as a "Local Extension."

   This includes, but is not limited to, critical local metadata fields such as:
   - Provenance/Donors: 541, 561, 700, 710
   - Local Subject/Genre Terms: 653, 655

   (Per OCLC standards, the full range of valid fields includes: 026, 037, 246, 361, 500-501, 506, 526, 533, 538, 540-541, 561-563, 580, 583-585, 588, 653, 655, 700, 710, 711, 720, 730, 740, 758, 773-774, 787-788, 790-793, 796-799, 800, 810, 811, 830, 880, 885, 896-899).

   Why This Matters to the Community:
   Implementing this change will bring Alma into alignment with standard MARC21 practices for institution-specific data. It eliminates the indexing gap in Primo, reduces metadata duplication, protects local data integrity in consortia (NZ), and removes the need for complex normalization and merge rules.

   The Problem:
   Alma’s current "Local Extension" model restricts local data to a hardcoded subset of tags (09X, 59X, 69X, etc.). This forces libraries to choose between keeping standard local data in the Network Zone (where it risks being overwritten) or moving it to non-standard local tags.

   When standard data (like a 700 donor name or a 655 local genre heading) is forced into a 9XX or 69X field, it breaks standard Primo indexing. We lose the ability to have this critical local data indexed in standard Primo indexes.

   The Solution:
   Update the Alma Metadata Editor and bibliographic validation rules to… more

   12 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

7. Save certain subfields from being overwritten via F3 and PTC

   When linking names, subjects etc. from authority files in various BIB fields, some cataloguing conventions require giving additional information in certain cases.

   One example for such a requirement, stemming from the German speaking countries, is to add the time and place of an auction when linking to the genre/form term “auction catalogs” in BIB field 655 (see attached screenshot). This additional information is, of course, specific for each BIB record and must not be overwritten or deleted, if at a later point in time either PTC processes said BIB record or a colleague invokes the F3 functionality.

   Since different subfields might be used for various types of additional information, based on the field number and the cataloguing tradition and/or authority file linked to, it would be sensible to allow to define specific subfields to be exempt based on the field number, but also the authority file in use ($2).

   When linking names, subjects etc. from authority files in various BIB fields, some cataloguing conventions require giving additional information in certain cases.

   One example for such a requirement, stemming from the German speaking countries, is to add the time and place of an auction when linking to the genre/form term “auction catalogs” in BIB field 655 (see attached screenshot). This additional information is, of course, specific for each BIB record and must not be overwritten or deleted, if at a later point in time either PTC processes said BIB record or a colleague invokes the F3 functionality.

   Since different subfields… more

   •  

   264 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   9 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   AdminErez Shabo (Product Manager, Ex Libris) responded

   Hello everyone, for those who raised comments about the correction of 830 $v, could you please provide a detailed, step-by-step explanation of the scenario in which this subfield gets overwritten?

8. Add an API endpoint to rerun an import profile job that failed

   We are monthly running an automated import profile to import electronic resources. Almost every time the import profile job finishes with status Completed with Errors and needs to be manually "rerun". This is a documented behavior: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/040Resource_Management/060Record_Import/080Monitor_and_View_Import_Jobs#Rerun.

   We would like to have an API endpoint through which we can simply rerun the import profile job that have failed due to the error "Failed in Commit after calling NZ" in some of it's files. This would allow to have the whole import process truly automated and without the need to manually intervene every time it runs.

   34 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Allow for an authority file to be addressed by different codes in $2 of various BIB fields

   In Alma the authority file, a subject or term stems from, is defined by the content of $2 in various 6XX fields. This code controls the F3 functionality, as well as the linking process and the various jobs like PTC. Each and every authority file is addressed by one specific code.

   In the German speaking countries we use an integrated authority file (GND), which amongst names and subjects, also includes genre/form terms. For historical reasons the genre/form terms in BIB field 655 are marked with the official LoC /MARC Genre/Form Code and Term Source Codes “gnd-content” and “gnd-carrier” in $2, while the terms are, as the code suggests, actually a subset of our integrated authority file “gnd”. The same goes for notated music terms in BIB field 348. These too are a subset of our integrated authority file and are marked by the official LoC /MARC code “gnd-music” in $2.

   Alma currently does not allow to link the above mentioned terms to said authority file, because the content of $2 does not exactly match the code for the authority file, which is “gnd”. This problem could be solved by allowing for different codes in $2 to address one and the same authority file.

   In Alma the authority file, a subject or term stems from, is defined by the content of $2 in various 6XX fields. This code controls the F3 functionality, as well as the linking process and the various jobs like PTC. Each and every authority file is addressed by one specific code.

   In the German speaking countries we use an integrated authority file (GND), which amongst names and subjects, also includes genre/form terms. For historical reasons the genre/form terms in BIB field 655 are marked with the official LoC /MARC Genre/Form Code and Term Source Codes “gnd-content” and “gnd-carrier” in $2,… more

   152 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Modification date of records that were processed via running a job but no modifications were made, should not change.

    When a record is included in a set and any job runs on that set, such as a normalization job, the modification date of the record is updated even if the record itself was not changed. This means the modification date is updated by design in Alma after processing or saving the record. Therefore, it is not currently possible in Analytics to run a report to check how many records were actually updated/modified in the job.

    8 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

11. Allow a NR to run with the PTC job

    TL;DR:
    We would like to have the ability to run a normalization rule whenever the PTC modifies a record.

    Background:
    In November 2024 Ex-Libris added a new functionality to the PTC job:
    MARC 21 Preferred Term Correction Can Flip Headings with Cross-Reference in Different Field
    https://knowledge.exlibrisgroup.com/Alma/Release_Notes/2024/Alma_2024_Release_Notes?mon=202411

    Problem:
    The PTC job only changes the first indicator correctly when the PTC job changes a field into 630.
    in all other cases, the existing indicators remain.
    We opened a case and spoke directly with Ex-Libris, but were told that the PTC job runs as intended, and that not handling the indicators is not a bug.
    I understand that other institutions have different reasons for having a NR run whenever the PTC changes a record.

    Request:
    We would like to have the option to add a normalization task to the PTC in the configuration menu, that way we will be able to fix problems that arise from this job.

    TL;DR:
    We would like to have the ability to run a normalization rule whenever the PTC modifies a record.

    Background:
    In November 2024 Ex-Libris added a new functionality to the PTC job:
    MARC 21 Preferred Term Correction Can Flip Headings with Cross-Reference in Different Field
    https://knowledge.exlibrisgroup.com/Alma/Release_Notes/2024/Alma_2024_Release_Notes?mon=202411

    Problem:
    The PTC job only changes the first indicator correctly when the PTC job changes a field into 630.
    in all other cases, the existing indicators remain.
    We opened a case and spoke directly with Ex-Libris, but were told that the PTC job runs as intended, and that not handling the indicators is not… more

    47 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. ensure that when 'po_line_description_update_upon_bib_change' enabled, subfield A does not get overwritten by subfield L in 022

    Sharing description from our Cataloger, CH:

    We believe the following describes a defect.

    Support indicates it is an enhancement request and suggests we propose on Idea Exchange.

    Background:
    1) We turned on the ‘polinedescriptionupdateuponbibchange’ enhancement in the sandbox.
    2) The enhancement overwrote the $$l instead of pulling in the $$a from 022 – this behavior describes a defect
    None of the following 3 options allow us to properly use the ‘polinedescriptionupdateuponbibchange’ enhancement:
    1. Ideally, we want to enable the ‘polinedescriptionupdateuponbibchange’ function to auto-sync changes in the bib record to the POL bib description. This saves our Cataloging team from an additional step to manually edit the POL record.
    However, we are unable to use this Alma function at all because when we do, it auto-reverts the POL bib desc ISSN from $$a to $$l.

    1. Less ideal, we use the Reload Bib Data button to sync changes in the POL bib desc to match the bib record (a more manual approach—it means our Cataloging team needs to click the ‘Reload Bib Data’ button).
       However, again, we are unable to use this function because this option also changes the ISSN from $$a to $$l. Another Alma feature we are not able to use.

    2. Least ideal – Cataloging team manually updates every field in POL bib desc to match bib record updates. This is the most work for the Cataloging team, as it does not allow them to use the 2 previous enhancements in Alma to make their jobs easier. With this feature enabled, if the Cataloging team manually types anything into the ISSN field in the POL bib description, the system will auto-revert to $$l and override manual changes. Once the Cataloging team makes any change to the ISSN field in the POL bib description, they CANNOT revert it back to $$a. It's as though they lost control of that field entirely. This feels to our organization to be a major glitch - why doesn't the system allow the user to make and save a MANUAL change to a field?

    Sharing description from our Cataloger, CH:

    We believe the following describes a defect.

    Support indicates it is an enhancement request and suggests we propose on Idea Exchange.

    Background:
    1) We turned on the ‘polinedescriptionupdateuponbibchange’ enhancement in the sandbox.
    2) The enhancement overwrote the $$l instead of pulling in the $$a from 022 – this behavior describes a defect
    None of the following 3 options allow us to properly use the ‘polinedescriptionupdateuponbibchange’ enhancement:
    1. Ideally, we want to enable the ‘polinedescriptionupdateuponbibchange’ function to… more

    10 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. Quick Links and Keyboard Shortcuts in the Metadata Editor for Enhance the Record Normalization Processes

    As a cataloger, I want to create quick links and keyboard shortcuts for normalization processes in the metadata editor, instead of selecting them via "Enhance the record", so that I can work more efficiently.

    5 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

14. Please allow manual reordering of record fields inside the MDE, particularly Dublin Core records.

    Within Alma search results, dc:creator doesn't display accurately if dc:contributor fields are present. Alma's internal logic displays the final dc:creator or dc:contributor field from the record as the primary creator within search results by digital title. There is no way to force a save or to "lock" the fields in the record within the Metadata Editor to accept dc:creator as a field AFTER dc:contributor. Upon "Save", the dc:creator is always reordered above dc:contributor. This has led to staff confusion when searching within Alma.

    1 vote

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

15. Reloading several records from the union catalog at once

    I would like to update several records from the union catalog at once, for example all the records within an itemized set. So far, this is only possible for individual records in the MDE ("Reload record from central catalog"), which is rather exhausting. It would be much easier if there was a button saying "reload records" by which you can push all checked items to the MDE and simultaneously reload the records from central catalog.

    In this way, we could easily and quickly update bibliographic records from the "Failed to update delete" event in Analytics. Another use case would be changes to periodical records that would otherwise not appear in the records of the related volumes.

    I would like to update several records from the union catalog at once, for example all the records within an itemized set. So far, this is only possible for individual records in the MDE ("Reload record from central catalog"), which is rather exhausting. It would be much easier if there was a button saying "reload records" by which you can push all checked items to the MDE and simultaneously reload the records from central catalog.

    In this way, we could easily and quickly update bibliographic records from the "Failed to update delete" event in Analytics. Another use case would be… more

    42 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. Expanding Unicode Tool range in Metadata Editor

    The new Insert Unicode Characters tool in the Metadata Editor should be expanded to include the 0300-036F range of characters. This range includes several diacritics that are commonly used by catalogers, including the ligature (0361), candrabindu (0310), and combining diaeresis below (0324).

    19 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

17. MDE Virtual Keyboard – Add Welsh as a separate language option.

    The new Virtual Keyboard for Inserting Special Characters and Diacritics in the Metadata Editor has many different language options. However Welsh is not amongst them.

    Can Welsh be added as a separate language.

    22 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

18. Support MARC 956 thumbnail images in Alma Staff Interface

    Description:

    Currently, Alma Staff Interface does not display thumbnail images originating from MARC field 956, even when these thumbnails are correctly displayed in Primo VE through thumbnail template configuration.

    At the moment, Alma Staff Interface only displays cover images resolved through internal mechanisms such as:

    ISBN-based cover services (MARC 020)
    Digital representations
    Internal cover enrichment services

    This creates an inconsistency between Primo VE and Alma Staff Interface.

    For example:

    A thumbnail image linked through MARC 956 appears correctly in Primo VE.
    The same record in Alma Staff Interface continues to display only the default placeholder icon.

    It would be very useful if Alma Staff Interface could also support thumbnail display from MARC 956 URLs, similarly to Primo VE.

    Benefits:

    Better visual identification of records by catalogers and library staff
    Improved consistency between Alma and Primo interfaces
    Greater flexibility for institutions that maintain their own thumbnail repositories or use external image sources
    Reduced dependency on ISBN-based enrichment services

    Suggested enhancement:
    Allow Alma Staff Interface to use configurable MARC fields (such as 956) as thumbnail sources, similarly to Primo thumbnail templates.

    Description:

    Currently, Alma Staff Interface does not display thumbnail images originating from MARC field 956, even when these thumbnails are correctly displayed in Primo VE through thumbnail template configuration.

    At the moment, Alma Staff Interface only displays cover images resolved through internal mechanisms such as:

    ISBN-based cover services (MARC 020)
    Digital representations
    Internal cover enrichment services

    This creates an inconsistency between Primo VE and Alma Staff Interface.

    For example:

    A thumbnail image linked through MARC 956 appears correctly in Primo VE.
    The same record in Alma Staff Interface continues to display only the default placeholder icon.

    It would be very… more

    1 vote

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

19. Display personal metadata editor history of opened/edited records

    Currently in Alma's All Titles search you can see a list of records you have previous looked at, but it would be helpful in the metadata editor if you had a list of records that you have opened recently. Even a list of 5-10 would helpful.

    9 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Add full MARC records to CZ for Mohr Siebeck

    This collection of Mohr Siebeck eBooks contains many titles with metadata that are too poor and need to be enriched. Could you please follow up with Mohr Siebeck?
    MMS-ID: 9919375751300041
    Thank you for your intervention!
    Kind regards,

    1 vote

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Metadata Management  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating