We want options that can prevent two Alma BIBs from being merged by Primo Dedup Process.
It could be an option per pipe or local record, or any better method. (Related SF Case# 00872193, etc.)

e.g.)
* Alma-P : Dedup OFF
* Alma-E : Dedup ON
* CDI : Dedup ON
.
.
.

Currently Primo runs dedup process for all records. (Please correct me if I am wrong.)
It is a necessary and useful function for electronic resources - especially for articles- but sometimes not for local print materials.

Catalogers decide whether to maintain separate BIBs or to merge them based on the phisical/bibliographical differences between similar titles.
When the decision was made to maintain them separately, it is intended that users will distinguish them and use the one they prefer. We also think it is users' right of selection.
However, current all-or-nothing process does not allow users to recognize the differences between the similar but unique physical items on different holdings by presenting them in one merged record.

We would appreciate if you kindly provide us a good solution for that.

There is a significant gap in Analytics recorded actions for user engagement with electronic resources directly in our Primo environment.

In Classic UI, this was partially possible by GetIt Link 1 and GetIt Link 2 actions, but invoked by a user clicking on the Get It tab, rather than an actual link.

This aspect is not even possible in New UI with a known gap for years for these GetIt actions.
Link Resolver Usage data is partially recorded in Alma Analytics, dependent on configuration.
This situation of data loss will be even more of an issue on CDI, with the drastic increase in Link in Record collections.
Why are there dozen of actions recorded for the different options in the Links section, and also Lateral Links in the Details section, and yet not the most important links of all, under View It in the Get It section?

This data should be comprehensively available in Primo Analytics, by adding the following 3 new Actions to the Primo Analytics Action Usage Subject Area:
Action group: Document
Subgroup: Get It
Action: Click on Link in Record link - remote
Action: Click on Link in Record link - local
Action: Click on Link Resolver link

If I've missed any variations and others should be listed, then please take this submission in the spirit it is intended, and cover all scenarios.

I also recognise of course that the Link Resolver piece is Alma expressed in Primo, but am adding this submission here because of the end goal of holistic tracking of these clicks in Primo

This should be added for both Primo deployment models of Primo via Back Office and Primo VE.

I've learned that the book cover images from Syndetics in Primo comes from the first Addata: ISBN PNX field which comes from the first subfield a in the MARC 020 field.

Often, we have the electronic version of a book that uses a different ISBN in the first MARC 020 |a

Small presses/publishers may have only sent Syndetics a print ISBN image and that image is available from Syndetics. Since often the print ISBN is in the MARC 020 field already - but not necessarily in subfield a or in the first position - it means that the default book image displays in the catalogue instead of a cover image.

Can you do something so that the system cycles through all of the ISBNs in a record until it finds an image? For example all of the ISBNs in the MARC 020 could be listed in the Addata: ISBN and then the system can systematically go through them until it finds one with an image to use?

That would be better than contacting Syndetics with a requeest to copy the printISBN image for use with an e-isbn and prevent us from listing incorrect ISBNs in the MARC 020 |a field just to force a book cover to display

Thanks for considering. Sandra.

Please do not use language filter when CDI merges records. It creates multiple records for one article, which confuses our patrons. (Case 00881023, 00824833) If CDI cannot merge them well, please provide a kind of "See Also" link to other records which have the same DOI. (CDI e-book records already display "Chapters of this book" link under the availability status.)

Many of non-English articles have English version metadata too because many journals oblige it. Western aggregators index English metadata whereas local aggregators index local language metadata. The problem is most of times they don't care about the language of the full-text but of metadata. So in those cases the language facet is useless because when our patrons open the full-text of a English record the full-text is actually written in non-English language.

When one of the records (or both) has linking problems, the situation gets worse. One of my patron was so upset and pointed out it's hard to imagine that somewhere on the search result list there might be another record in different language for the same article. It's understandable, because only the volume and issue number and the page ranges are identical on the list.

If Primo provides the link to the other records for the same article, it will be more discoverable. The chance is low that the original article and its translated version (if it exists) share the same DOI, so it could be used to create the link.

Many users at our institution simply want to browse the most recent issue of a newspaper we have a subscription to. They are not searching for specific articles.

It would benefit our users if the newspaper search results provided easy access directly to the record (and view-online link) for a specific newspaper title. Perhaps this could be similar to the "Highlight Reference Entry On Top" where the appropriate record is pinned to the top of the results.

So, a Newspaper Search for "New York Times" ought to pin the title-level bibliographic record (that our institution has full access to) to the top, while the article-level records are displayed in the search results.

When there are records in CDI that have link in record, but also would return links from the link resolver both types of links should be displayed to the end user.

The challenges with the link in record are discussed in this idea: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/40487230-preference-cdi-link-resolver-records-over-link-in

They have a tendency to break and if the link for some reason do not lead to the full text the end user does not get any other way to the full text (as they do with the multiple links fromt he link resolver).

We hope that Ex Libris enables the system to display both link in record links and link resolver links for the same item.

This should be done for both Primo and Primo VE. If this should be configurable can be discussed with the Primo Working group.

Our library would like you to add a second email address option to those provided in the email dialogue box accessed from My basket so that clients can send a list of items for click and collect to both the Library email and their own email as cc if desired. (Some clients may not wish to use this option, so it should be optional and not essential.)

Also please add another slot to the dialogue box specifically for the name of the patron to be inserted before the slot for the notes, i.e., Name of patron: John Smith
This slot should be automatically populated when the dialogue box pops up if possible.

Our library would like you to add a second email address option to those provided in the email dialogue box accessed from My basket so that clients can send a list of items for click and collect to both the Library email and their own email as cc if desired. (Some clients may not wish to use this option, so it should be optional and not essential.)

Also please add another slot to the dialogue box specifically for the name of the patron to be inserted before the slot for the notes, i.e., Name of patron: John Smith
This slot should be automatically populated when the dialogue box pops up if possible.

It's now possible to select and act upon a set of 50 records in Primo VE. However, once the first set of 50 records has been selected and saved to Favorites (or otherwise acted upon), all actions on additional records must be done manually, one at a time. After the first 50, the user gets the message, "Please edit your selection to include no more than 50 records." and then it is no longer possible to work with records in batch.
For example, often a user will perform a search in Primo VE and find a set of 150 or more records of interest to their research. Currently, the user can Choose the Top 50 results and save to Favorites; then Load More Results, page by page (10 results per page); then Deselect the original 50 selected; then begin with record 51 and individually select each record to select records 51-100, and add to Favorites; then repeat the deselect, load more results, individually select records process to add records 101-150 to Favorites; and so on. Acting upon the first set of 50 records is easy, but the manual work to capture and work with records 51-150 (etc.) is both cumbersome and challenging.
It would be great if it were possible to Choose the Next Top 50 Results to work with them in batch, as well.