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.

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.

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.

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.

Currently the only way to use records from NZ in an IZ is to search them in the NZ and perform an action like "order" or "link" on every single record one by one. There are, however, situations where an IZ wants to use a bulk of records. For this purpose we need a possibility to link records in bulk and create inventory for the linked records.

We imagine a linking job that takes as an input a logical or itemized set of records saved from a search in the NZ. The linking job can create physical and electronic (and digital) inventory, similar to current import profiles. The inventory operations for electronic inventory should include an option to specify the desired action if the record and a portfolio exist already in the IZ, out of the following choices:

- Add new portfolio.
- Update portfolio information (the URL).
- Don't do anything.

Use case:
The NZ loads monthly updates from e-book vendors where the IZs have purchased different packages. The workflows for group inventory aren't applicable here because the NZ doesn't possess the necessary information for determining who has rights to which portfolio. OAI is no option because this currently creates duplicate portfolios each time a record gets updated in the NZ. The workarounds currently in place involve sending files back and forth which is error prone and not very efficient.