With CDI we have no control over preventing CDI content from appearing in our Primo filtered search, when we have full text holdings which matches to this content.
In many cases this may be a good thing, in not needing to worry over making sure full text content is searchable.
However, it is clear that there are collections in CDI with very poor data, which causes linking to fail, and also has content which we do not want at all such as Journals and Books, as we manage the title level by our Alma records.
For example, CRL Catalog has 76,000 Journal records, which duplicate our own records and many of them are failing Link Resolver requests. LIBRIS has similar issues and content, and so does DataCite.
In just one day of Link Resolver data, for CRL we had 17 of 49 requests fail (34%), and for DataCite we had 27 of 124 requests fail (21%).
These numbers are all real users who are having a poor experience in our Primo environment and building a terrible impression of our Library service.
We should be able to remove this content by Alma Electronic Collection, with this content not appearing in our Primo environment if the CDI Electronic Collection is not in our Alma environment, such as not in our Institution Zone, or a new CDI setting to achieve this.
Please restore our autonomy to remove this content, so that we can offer our users a stable and consistent experience.

Please add a new Rapid ILL lending status field to electronic collections so libraries can indicate the following Rapid ILL lending statuses and more easily create logical sets to automatically send holdings to Rapid:
• LendableInternational: You are able to fill lending requests from any other Rapid libraries around the world. This is typically the Lendable value used for print materials that you want to make available in Rapid.
• LendableCountry: You are able to fill lending requests only from Rapid libraries in your country. This is typically the Lendable value used for electronic materials.
• LocalOnly: You are not able to fill lending requests from other Rapid libraries, however these items are still available to fill your local patrons’ borrowing requests.

Currently, the documentation suggests putting these labels in electronic collections’ internal notes field. https://knowledge.exlibrisgroup.com/RapidILL/ImplementationGuides/AlmaHoldingsHarvestfor_RapidILL

It would better to have a dedicated field in electronic collections where a Rapid lending status value could be selected.

Libraries should also have the ability to perform bulk changes to this field via the E-Collection Quick Update Cloud App.

Alma portfolios in the IZ show a modification date in their history when a change is made based on CZ data. However, the changes themselves are not documented in the portfolio's history tab -- just the fact that a change occurred on that date.

Some changes are displayed to users in the CZ updates task list, so it's clear that Ex Libris has a way to communicate this at the Institution level. But as Update Task List entries can be dismissed en masse, it's important to reflect CZ changes like linking and coverage dates in a more persistent manner, through the history tab.

This Idea is a followup to Support Case #00903195.

CZ collections vary in regard to the quality of their metadata. Some CZ collections contain rich MARC records, while others contain very poor records. When facing the question whether to import vendor's MARC records or to rely on CZ records, librarians usually lack basic information about the quality of existing MARC records in a given CZ collection.

I would like to suggest that each CZ collection will include basic statistical information about the MARC records quality. Such information could be generated in different ways.

One possibility is to provide an analysis based on predefined quality profiles of MARC records. Here, specific profiles of MARC record quality would be defined (such as: 'brief', 'basic' and 'rich'), this in accordance to the type and number of MARC tags included in each profile. Based on those predefined quality profiles, each collection would then include a summary of the percentage of records fitting each quality profile. The librarians could see that CZ collection 'X' contains 10% 'brief' MARC records, 60% 'basic' MARC records, etc.

Second possibility (complementary to the previous), would be to provide a general MARC tags count for all the collection records. Here, librarians would easily see the frequency of each MARC tag in the records set. With this information provided, it would be easier for librarians to assess the MARC records quality of a collection, judging by the percentage of records that contain certain tags, as ISBN (020), ISSN (022), subject heading (6xx), etc. Preferably, within the CZ collection view, librarians would be provided with a summary of the information, focused on several important tags (ISBN/ISSN, authors, subject heading, etc.), and an option to download a full frequency analysis report.

Post migration we had a lot of electronic resources that migrated to Alma as standalone bibs with no inventory or portfolios attached. Best practice in Alma for e-resources management would be to have portfolios attached to all of these records and to have as many of them sorted into local electronic collections as possible, so that global changes can be made from Admin by running a job.

The process of manually adding local portfolios to each of these records is cumbersome. This idea would be to have a Create Electronic Portfolios Job that could be run from Admin on a set of bib records. This would be similar to the Add Local Portfolio Job, but fields such as title or URL would be automatically mapped from the 245 and 856 fields respectively.

When deleting portfolios individually or through a batch process, add a feature to flag/warn about portfolios with perpetual or current plus perpetual for the access type before they are deleted. It could be similar to the message and process you run into upon trying to delete a portfolio with an active po line or a physical holding with an active po line. My library's portfolios attached to larger collections often do not have PO lines (as much of this work was done in our former library system prior to Alma migration). Adding a perpetual access type to portfolios is relatively easy to do. If tied to deletion prevention, it would help secure content a library does not want to delete. Thanks for your consideration.

Include parser override values in it's own column in extended export report

It's not possible to view which portfolios in a collection have parser override values. Currently, the value is included in the parser parameters value in extended export reports.

It would be helpful with managing portfolios to have a way to see when a portfolio has a parser override value. That way, we could check on those portfolios and make sure the CZ parser value has been corrected.

Please, include parser override values in it's own column in extended export report or have another way of highlighting when an override value exists.

We use the autoload feature to update electronic holdings for specific vendors such as ScienceDirect and Ovid.

After autoload, we find that the job will list out the no. of portfolios “added”, “updated”, and “deleted” but without the deleted titles listed out at the job report. Whenever a portfolio is deleted, we need to check if the deleted titles are removed correctly? Do we have perpetual access right for the deleted titles and do we need to claim for the access right with the new publisher.

We use the load portfolios tool in the Electronic service to add/update/delete portfolios for collections without the autoload features. We can validate online or download the action list to check if the add/delete/update actions are really want by us before performing the update. Why the same validate file is not available for the autoload function and the deleted titles cannot be listed out for follow up action? I really appreciate if ExLibis will consider it and include also the deleted titles in the report for the customers to check and follow up.

Currently to manage the order and organization of license terms in Alma, we have to number each term we wish to use in order. If we want to add or reorder, we need to carefully renumber the existing terms so we don't accidentally use the same number twice and risk overwriting existing terms. While we've all learned work-arounds for this, given the amount of work it takes to maintain our hundreds of licenses, it seems risky to have this form of ordering. It would be much better to have the functionality that appears elsewhere in Alma that allows for lines to be moved up and down in a list. This would prevent any accidental overwrites. This functionality appears elsewhere in Alma so it would be useful to apply it in the license config.