It would be useful if item policy could be configured as a field to display in either the brief or full item display. Currently, the loanable indicator is defined by the fulfillment terms of use, which is dependent on users signing in in order for Primo to calculate the loan policy specifically for that user.

Having the option to display the item policy from Alma as a field in Primo would be beneficial as this does not change dependent on the user type or fulfillment rules. It would also provide more information to users irrespective of whether they are able to sign into Primo (e.g. users not affiliated to the institution will be unable to sign in) and makes it clearer and easier for staff to explain to customers why a particular item can/cannot be borrowed.

When filtering to a certain location via facets, you often get results from other locations too, which is unexpected from patrons perspective in many cases. This is caused by the current related records setting which is also taking locations with related records into account. The display is correct for analytical records without inventory (book chapters and articles), but not for the other monographical resources.

What we wish to achieve is the following:

When the record of a book chapter, journal issue or journal article (i.e. a record containing a 773 field with $w) is viewed in Primo, the holding of the record linked via 773 $w is displayed.

When records contain a series link (8xx $w) or a related record (76x/77x/78x $w - exception: 773), we do wish to display a link to the related record (via system number), but not the related holding.

Right now, the configuration does not offer the needed flexibility.

The configuration options for facets in Primo VE are currently very limited, and not at parity with Primo on Back Office. It is not currently possible in Primo VE for a single record to have multiple facets or prefilter resource type values, to better align with CDI in a blended search, it is not possible to configure the facet and prefilter resource type values separately and independently of the display resource type values, and these facets cannot be configured with sufficient granularity. As examples of this configuration issue to be made possible with this request: Example 1: Our display types are mostly based on physical format: print books, ebooks, microforms, audio CDs and so on. However, because we are able to apply multiple facet values to a record, those items above might also be able to facet as a dissertation or conference proceeding, etc. Our users are accustomed to being able to facet or limit by those multiple values. This difference in behavior can be seen in a search for "conference" in Primo Back Office (https://tinyurl.com/1ouvijhn) vs. our test instance of VE (https://tinyurl.com/16j67u7t). In the Primo Back Office version, more records are identified as conference proceedings because we use more strategies to identify them as such. Also, if one limits to conference proceedings, they can then further limit by format, such as print book or audio CD. For prefilter, we also incorporate multiple resource types together into a single category (e.g., audio or video). This enables us to help users who are only interested in a specific format, such as streaming video, as well as users who wish to search for audio or video more generally. Example 2: As an example, we treat the audio and video resource types differently for facets and prefilter within Primo Back Office. For facets, we identify the specific resource type: e-audio/streaming audio, audio CD, audio cassette or LP. However, for prefilter, we incorporate these resource types together into a single audio category. Example 3: Applying the Local Resource Type “Microform” would replace the primary original resource type “Book,” “Journal,” “Map,” etc. – but in fact both the physical format “Microform” and the original resource type “Book” or “Journal” or “Map” would be needed.

We would like to have more flexibility with Primo VE resource types and the related facet and prefilter values. There are situations in which we would like to be able to add records to an OTB resource display type that don't meet the OTB conditions. For example, for certain textual integrating resources that users are likely to think of as books, we use conditions based on the presence of form/genre headings to add them to the OTB ""book"" display type in Primo BO (e.g., open textbooks that are periodically updated: https://searchit.libraries.wsu.edu/permalink/f/j5jme3/CP71251613210001451). Conversely, we would sometimes like to be able to exclude records from a particular OTB display type.
Here are two possible ways to accomplish this request:
1) Make the OTB resource display type rules locally editable.
2) Use a local field to override the OTB resource display type rule. For example, 999 $a could be defined as the local override field for resource types. Each OTB resource type could be associated with a code that could be added to 999 $a to force that record to have that OTB resource type.

Conditions could be added to the OTB rules as follows in this example for conference proceedings:
--If 999 is null, then execute the standard OTB rule for conference proceedings
--If 999 is not null, then check if 999 = ""conferenceproceeding""
-----If 999 = ""conferenceproceeding"" then mark record as conference proceeding #force include
-----If 999 != ""conference_proceeding"" then do nothing #force exclude

When our users look for a book in the Primo Search Portal they expect that the Primo Search behaves like a Google Search, i.e. they expect that Primo finds books with titles or metadata containing words similar to those in their query. Unfortunately, the Primo Search is very sensitive to the exact spelling of the words in the query. If the search query is slightly inaccurate, the book is not found in Primo. I tried such unsuccessful search queries on www.amazon.de, and Amazon usually found the correct book: Amazon showed the correct hit on top of the list (see attachment). This shows that the search algorithms of Amazon are clearly superior to those of Primo. I feel that Ex Libris should take steps to keep up with modern search technologies.
Some, but not all, of Primo’s shortcomings seem rather easy to fix. Primo fails to take word flexions in non-English languages into account. Since the endings of German words not only depend on plural and singular but also on the context, Primo’s search results for German queries are overly sensitive to word flexions. However, some of the English examples indicate that improving Primo’s dictionaries will not be sufficient. Over the long term, ExLibris may consider to team up with a specialized search provider.

Similar proposals in ExLibris idea exchange
https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/37586617-increase-primo-search-capability-to-support-major
https://ideas.exlibrisgroup.com/forums/564566-summon/suggestions/17415091-automatically-searching-for-the-corrected-spelling

In the brief and full display pages, libraries can display information contained in data fields (such as the title, author, and creation date) from the source record. This information helps users to differentiate records quickly. In some cases, there can be a lot of information that is displayed. This is particularly the case when Contributor is added: all 7XX fields are added, and in their entirety (see for example in the attached screenshot).

We would like an option that would allow the library to either limit the number of fields to display (for example max 3 7XX fields) or to only display fields based on the content of some subfields (for example: only display 7XX where $$e equals 'editor', 'publishing director ', 'translator', 'Director', 'film director'...).

Primo VE is configured to map 6XX $v form subdivisions to a separate display field, breaking the subject string. In some cases, the form subdivision is plucked out of the 6XX, leaving the surrounding string incomplete. For example:

600 10 $aO'Keeffe, Georgia, $d1887-1986 $vExhibitions
displays in Primo VE as:

Subject O'Keeffe, Georgia, 1887-1986

Genre Exhibitions

651 #0 $aRome (Italy) $vMaps $vEarly works to 1800
displays in Primo VE as:

Subject Rome (Italy)

Genre Maps
Early works to 1800

And so on, for all 6XX $v form subdivisions. This cannot be reconfigured. Additionally, each occurrence of the form subdivision is displayed as a separate genre. An exhibition catalog with three artists appearing in 6XX fields would result in three genre term displays, all saying "Exhibitions".

To preserve our subject string with form subdivisions intact, we were advised to consider adding a 9XX with the field as we want it to display and labeling that as Subject in Primo VE.This adds steps to cataloger workflow and generates unnecessary data in the records.

This display feature should be reconsidered. Whether or not to split $v form subdivisions should at least be configurable by libraries.

Hi
We're in a consortium, using Primo VE.

Our first two search scope slots are
– IZ
– NZ plus CDI

It is possible to show a facet 'Other libraries', which shows the libraries outside our own IZ.

But 'Other libraries' can't be customized like a normal facet:
– it can't be displayed only in the search scope slot NZ/CDI without being displayed in the search scope slot IZ
– it can't be separated from the facet Libraries and for example put last in the list of facets
– it can't be collapsed if the facet Libraries is not collapsed

Showing libraries from outside our IZ in the search scope slot "IZ" is too confusing.

So for the moment we are hiding 'Other libraries' altogether. But we would like to show it in the search scope slot "NZ/CDI".

https://basel.swisscovery.org

FRBR groups and the display of versions within them does not consider the relevancy of the terms searched. Often a user is searching for a specific version within the FRBR group (ex: Homer's Iliad translated by Richmond Lattimore) but there is no way to focus in on this version within the list of FRBR versions. Even when users search specifically for terms: Iliad Lattimore, Lattimore is hidden within search results. Within the list of FRBR versions, sorting by Relevancy should use the terms searched by the user -- this should enable the works of a single translator (like Lattimore) to rise to the top of the list of results when that translator's name is explicitly included in the search, greatly improving discoverability and access.

A multi-part resource (eg: a sketchbook containing 200 drawings) is catalogued in MARC 773 (host/item relationship). PrimoVE ought to sort and display the component parts using $$g and $$q. Currently PrimoVE fails to do this in the correct numerical order. Rather, the presentation is alphabetical which is useless for component-items organized by their part or page number. There was a recent ideas exchange issue raised on this very topic, which was “solved” by providing the aforementioned “alphabetical solution”. However, a NUMERICAL visualization has much more value in Discovery for patrons who are interested in locating an item as part of a host (the drawing on page number 12 of a sketch book, for example). This is a frequent and conventional library requirement for example in Special Collections communities, as it reflects accurately the sequential order within an actual work or a manifestation.
Currently (SEE SCREENSHOT BELOW) the user sees this rather wild presentation in PrimoVE (the resource is the sketch-book of 200 drawings cited above).

Another example from the world of monographs is a collection of Brecht’s works: currently looking like this in PrimoVE:

https://basel.swisscovery.org/permalink/41SLSP_UBS/1hbnn2v/alma993707790105504

The publisher’s website displays the correct sequence:

https://www.suhrkamp.de/werkausgabe/bertolt-brecht-werke-grosse-kommentierte-berliner-und-frankfurter-ausgabe-30-baende-in-32-teilbaenden-und-ein-registerband-leinen-w-17

I do not consider this request an “enhancement” feature, rather a basic library requirement, dating back to the traditional card-catalogue-era.

Many thanks.

In the current context of global health crisis and containment, many of our libraries can only offer Click&Collect service for physical documentation access. Then, it seems critical to make the request service evolve in Primo (and Alma for the tracking).
Indeed, a reader who wants to request several documents must do so one by one from the bibliographic record by selecting the "pickup location", possibly a "start date", an "end date" and a "comment".
Couldn't you consider the possibility of creating a basket and then being able to request the entire basket at once?
Thanks

This new demand could also help to resolve this existing demand:
https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/35709595-option-to-request-multiple-volumes