Because all norm rules can be edited by all staff with cataloger roles, there is great room for erroneous changes for rules that are applied to batch jobs. For example, the norm rule that is applied to records being brought in from Z39.50 targets can be edited by any staff member. A single error in the rule can break the z39.50 import process for all staff until the source of the error is identified. Likewise, if we have a rule applied to import profiles and a staff member inadvertently changes it and we load 50,000 records, that could cause huge data corruption. There needs to be a way to secure a norm rule to administrators such that normal staff with cataloger roles cannot change them.

Alma authority control does not handle cases where the bib heading is linked to an authority via a cross-reference, but the preferred and non-preferred terms are in different fields, e.g. preferred term is in authority field 130 and cross-reference in authority is in 410.

Alma should be able to handle this scenario. Currently when the bib heading matches the authority cross-reference, Alma won't correct these and instead puts them on this report: Preferred Term Correction - Bib Heading found no authorized term.

Example bib heading that Alma won't correct:

110/2_ $$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28.

The authority record that this heading links to (via its cross-reference)

130/_0 $$a Treaty of Versailles $$d (1919 June 28)
410/2_$$a Allied and Associated Powers (1914-1920). $$t Treaties, etc. $$g Germany, $$d 1919 June 28

The bib heading in 110 links to the authority via the cross-reference in the 410, but because the preferred term in the authority is in 130 (and not 110), Alma will not flip the heading.

When a 655 field is coded for LCSH and matches a non-preferred term in LCGFT, Alma flips the heading to the preferred LCGFT term but does not update the coding (it should change the 2nd ind to 7 and add $2 lcgft).

The problem is limited to cases where:

A bib heading 655/_0 matches a non-preferred term in an LCGFT authority

What happens is:

The PTC job flips the heading to the LCGFT preferred form, but it does not change the 2nd-indicator from 0 to 7, and does not add $2lcgft

What is not a problem:

655/_0 headings that already match preferred LCSH/LCGFT form
655/_7, $2 lcgft (these get controlled appropriately)
655/_7, $2 fast (these get controlled appropriately)
655/_7, $2 any other vocab (these do not get controlled)


Example of the bug:

Before: 655/_0 $a Dissertations, Academic
After: 655/_0 $a Academic theses.

Lists of Name Authorities similar Subject Authorities
When cataloging a bibliographic record, Alma allows selecting different lists of Subject Authorities (LC, UC or UANDES, etc.). In the case of the Name Authorities, it currently only allows the use of a list of Name Authorities. We propose that the authorities of name are handled in the same way as the Matter Authorities.

// Al momento de catalogar un registro bibliográfico, Alma
permite seleccionar distintos listados de Autoridades de Materia (LC, UC o UANDES, etc.). En el caso de las Autoridades de Nombre, actualmente sólo permite usar un listado de Autoridades de Nombre. Proponemos que las autoridades de nombre se manejen igual que las Autoridades de Materia.

Currently, the OCLC Number for a record is indexed in the search index "Other System Number." This is not ideal, since the Other System Number indexes other numbers related to vendor record, CONSER, related item, etc.
We request that Ex Libris provide a separate search index for OCLC number based on the presence of the '(OCoLC)' prefix in the 035 $a and/or $z, or (without prefix) in the 019 $a if there is a number in the 035 with an (OCoLC) prefix. Currently these specific (OCoLC) numbers are mixed in with other numbers occurring in the 019, 035, 773, 774, 775 777, 786, 800, 810, 811, 830 $w tags and subfields. Disambiguating these specific (OCoLC) numbers from the "other system numbers" would allow us to use them as unique identifiers. We see the potential for: Improved search Improved matching upon record import Cleaner Excel exports from Alma (we currently have to clean this field every time we export) Creation of a new Analytics field for OCLC number in Alma Analytics Establishment of a model for non-OCLC systems to create other unique search indexes 

Here is an enhancement request concerning bibliographic records editing history.

Currently, the "View Versions" can only tell the different version of a bib. record. However, this cannot tell logging history of updating/editing the bib. records, e.g. who add/remove a MARC fields/who suppressed/released the bib. record etc. This is no history tab to keep tracking the changes of a bib. record which is unlike other history tab functionality available in other Alma pages, e.g.

• The PO Line Summary page when editing a PO line
• The Physical Item Editor page when editing item records
• The License Terms Details page when editing license details

It is good to know logging history of updating/editing the bib. record for a record life cycle.

When we are searching WorldCat for a record to match a newly-ordered title, we often find duplicate records. The current search results display makes it difficult and time-consuming to choose the best record.

The external resources search would be much improved if we could limit search results by the language of cataloging (040 |b) and format. This would save us having to wade through multiple vendor records that aren't even in our local language of cataloging, and multiple records for resources in a format other than the one we are looking for.

It would save us a lot of time if the search results display showed the source of cataloging (040 |a |c) and the number of holdings in OCLC. These both help us choose the record we want to use. It is inconvenient to have to view each record to see its source, and as far as I can tell, there is no way in Alma to see the number of holdings on any WorldCat record.

Thanks for considering.

We would like to be able to copy multiple lines from MARC records and paste them into the metadata editor so that multiple MARC fields are pasted into the record in one action. This would help us enormously with our workflow of importing MARC authority records from LibrariesAustralia into Alma.

For us, this is necessary because the LibrariesAustralia headings are not in the community zone and are unlikely to ever be included there and Alma does not allow for Z39.50 import of authority headings.

We have this functionality of copying and pasting multiple fields in the LibrariesAustralia Cataloguing Client and other library systems allow it. At the moment we need to paste each line one by one into Alma and it is slow and repetitive. This process is a step backward from previous functionality.

Cataloging staff often need to create normalization or indication rules to edit groups of records. They can create these in the Medatdata Editor but they cannot use them on sets of records until they are added as a process/task in the resources metadata configuration area.

The ability to add processes is limited to the highest role of cataloger administrator which also allows configuration permissions.

Include the ability to add normalization and indication rule processes to the cataloger manager role to allow more flexibility to do global changes on Marc records.

Catalog managers need to add their own rules without giving them the ability to alter other configurations.

Would like the ability to set individual item records to not be published.

Historically, we did not create item records for individual serial issues, but created a fake item record to get usage which migrated over to Alma. These item records display to the user in Primo.

Our options to fix this would be to give them all a process type, and set that process type to not publish but many of our staff find work orders confusing and we would not like to complicate it further. Alternatively, we could move each one to a suppressed holdings record, which would be a very manual process.

So we thought it would be nice to be able to set individual item records to either not publish or to be suppressed from view.