There is currently no way to search across the sub-collections contained within a collection.

Currently, to search for a specific title you have to search across all collections at your institution or within the specific sub-collection where the title resides. This design is inefficient and counter-intuitive. In order to improve the collection discovery experience, it is important that users have the ability to search for any title contained within a collection and its sub-collections.

Users often wish to begin their searching within filtered sets of records, for example, by material type or language. Equally often, they would like to include multiple options within these filters, such as two or more languages or types. Selecting multiple options within a single facet group is possible after running a search, but it is not currently possible when pre-filtering in Advanced Search. The inability to apply more precise filtering is frustrating for the users who need and want to search as quickly and accurately as possible within only the materials and languages they seek. This frustration is increased by their inability to combine search results in Primo, as well as how commonly they can use multi-selection is in other search tools (such as WorldCat.org). This functionality would be the equivalent of the HTML select multiple attribute, which is also very commonly used and supported by all major browsers.

We would like to have a configuration tool to make the AI Research Assistant more flexible. Libraries should be able to choose whether to include all the CDI sources or only the activated ones. This may be useful to prevent the first results from being citations of resources not owned/activated by the library. Moreover, the tool should have the option to allow all the Boolean operators, not only OR.

CDI contains many records for abstracts of papers presented at conferences which are inaccurately described as "Articles." Example: https://www.screencast.com/t/uTqPWmYR7N and attached. This practice is not only misleading but also generates many false error reports from users complaining that they are unable to retrieve full text only to be informed that the abstract is in fact the full text. We ask that Ex Libris consider adding a resource type to CDI to indicate when a record refers to an abstract.

In Primo VE under Configuration > Discovery > Display Configuration > Labels > the excel export option only provides an export of the names of the Code Tables and not what is expected, which is an export list of all the Codes within all the Code Tables.

This is a significant downgrade in the option in Primo managed by Back Office to easily export all Codes in all Code Tables via General > Code Tables > Export. The BO file is not only easily obtained in moments, but also contains all the valuable data for good documentation practices with columns of Subsystem, Order, Creation Date, Update Date, Code Table Name, Code, Description, Translation, Installation Code, Institution Code.

In sum, the export from Primo Back Office is exactly fit-for-purpose to support Primo Administrator good practices with record keeping out-of-system for changes and transparent communication of these internally, as well as supporting configuration work to be done easily by search across the spreadsheet to identify labels needing changing.

There is a file attached to this product development request showing screenshots of the varying UI and snapshot export file example with these columns.

This request is to support Discovery Administrators with the same development in Primo VE, to export all Code easily in one file for all Code Tables with this associated data by each column.

Note: This product development request is submitted also as Ex Libris responses for related defects has proven far from supportive towards admins, and it worsens this loss of feature between Primo BO and Primo VE. This includes Ex Libris refusal to fix a defect when searching code tables that the filtering by the initial query is not shown in each table thereafter nor Code or Description field selection remembered, forcing repetitive re-selection and searching in each table (07184950), and refusing to fix a defect where searches of codes return false positives for tables which are subsequently found not to include that code (07184942 and 07807537). Ex Libris have also advised that they will not fix the issue of codes present but not utilised in Primo VE, as added during VE development in 2017 from original Primo Back Office codes (07200640). If Primo VE Discovery Administrators could at least quickly and easily export all Code rows from all Code Tables with all data per this submission, it would be a helpful workaround to Ex Libris not fixing the related defects.

Currently the last 200 research history topics stored for a patron when using the AI Research Assistant can only be deleted one by one.

There is no batch delete function and there is also no overall opt-out option.

The suggested enhancement for the research history topics storage function is to add:

1. 1. Multiple select / pin / export / delete options, similar to the existing functions of Primo My Favorites Search History, but including also an overall easy option to select and delete all 200 stored research history topics at once

2. Add an overall "opt-out" option for patrons who do not want their research history topics retained in the AI Research Assistant at all

For patrons who have selected to opt-out from research history topics being stored in the AI Research Assistant, anonymized history without linking to any patron record can be retained for Analytics or debugging purposes.

We need the ability to move to the top of the View It window a service with current access (this means the coverage statement is open-ended, ie Available from 1998 - current).

Currently, the Online Services Order only lets you move to the top or move to the bottom according to the service type, service name, or service value. None of these options take into account the coverage statement and sort according to current access.

Users get overwhelmed with the long list of services displayed in the View It window in Primo. Most commonly, users want to access the most recently published content. The existing options for sorting in the Online Services Order configuration do not address this user need. Services listed first in the View It window in Primo are the easiest for users to locate. Therefore listing services with current access first will help users locate the link most likely to fulfill their need.

We are proposing adding an option to Alma>Configuration>Fulfillment>Discovery Interface Display Logic>Online Services Order to move to top a service with current access.

Here are some potential ways to implement this:

Option 1: Allow portfolios with empty values in the Until Year/Until Month/Until Day/Until Volume/Until Issue fields in the Global Date Information/Local Date Information in the coverage tab, along with empty values in the Global Embargo/Rolling Year & Local Embargo/Rolling Year fields to be moved to top or bottom.

Option 2: if the Online Services Order can only take into account information in the Services record and not information in the Portfolio, a check box could be added to the Service record to indicate whether the attached portfolios have current access or not.

Option 3: add additional Service Types: Full Text-Current Access; Selected Full Text-Current Access.

The outcome would be that the sorting is consistent regardless of interface, electronic collection name, or whether the service is held in IZ or NZ. Users can easily distinguish between services with current access and those with only archival access (values in the previously mentioned fields).

Due to the planned developments in the area of ​​SSL browser certificates, which are being promoted by companies such as Google and Apple, the validity of browser certificates will be significantly shortened in the future (gradually down to just 45 days).

For institutions that use a custom domain to operate Primo VE, but also for Ex Libris, there is an increasing amount of work involved in updating SSL browser certificates. These costs could be significantly reduced by supporting ACME-like services to automate SSL certificate management.

In the result list a generic FRBR document does not show a cover image but only the generic FRBR icon. The result list would look much more attractive if also FRBR results had real cover images. Ideally, the real cover images of the top 3 FRBR results were used to form a fan of covers. So, the FRBR icon would only be used if there are no real cover images.

Users should be able to select sets from their Search History or Saved Searches and combine them using standard operators such as AND, OR, and NOT, with the system then processing and presenting a new set of search results based on the interaction between the selected sets. Combining searches is a very common, useful function in many library search tools and it would improve the user experience in Primo. Our researchers have frequently asked for this functionality.

Community colleges and other higher education libraries working with "first year experience" students often point to reference entries as helpful sources for novice researchers. These sources are useful when students are beginning to learn about a new topic and gleaning helpful keywords for deeper searching. The existing "Highlight reference entry on top" feature regularly surfaces an old entry for many popular entry-level research topics (even when many newer / broad / appropriate entries exist on the target platforms). We would like this feature to match with newer content on the target platform.

Users have requested that the institution's library, location, and call numbers be included in the Excel/CSV files they export from Primo so that they can use the exported files to find materials within the library’s shelves. The call numbers need to come from the holdings and item records and not the bibliographic record, since the bibliographic record field value may not be used by the local institution. This data can be added to the AVA field for Primo BO, but there is no equivalent configuration for Primo VE.

The number of "Local Fields using Search and Facet Normalization Rules" is set by default to 10, while the number of configurable local fields overall is 100. There is an option to increase beyond this by request through opening a Support ticket. We ask that the number of "Local Fields using Search and Facet Normalization Rules" could be raised to at least 20 without needing to open a Support ticket.

Note: This is a resubmission of a prior request: PENH-I-28079 (Primo VE: Local fields indexing).

Every time you want to test a rule for external resources, even just a small tweak, you have to upload the record, or copy/paste it. This is onerous and time-consuming and makes collaboration difficult. In Back Office the process was streamlined and much more efficient -- you could store multiple records in the system, and do iterative testing with ease.

Primo VE home page contains important information and often some notices, news, etc. needs to be inserted/deleted/changed with some urgency. Currently we need to download the view package, edit the html templates, repackage and upload the new view package again. It would be very useful to have an area (edit box) in Alma>Discovery configuration where we can turned on/off and easily enter text that is immediately made active/disactive in the view.

Currently, patrons have queried their request history with staff resulting in extra work for staff and delays for information for patrons as it involves either looking in the resource sharing requests system (resource sharing requests) or building analytics reports (patron physical items requests) for users to extract this information.- It is important for patrons to be able to see what they have already requested. If certain items are requested more than once copyright might be infringed. - Cancelled requests (by both the requester and the library) should be included- It should be possible to filter the list by request status and request type (patron physical item request, Resource sharing requests, etc.)- Alma Resource Sharing requests should be included. Our patrons previously used the Relais ILL system which permitted them to peruse historic requests. - The option could be made accessible as for My Account LOANS Previous and historic loans As a University's student / member of staff, I want to be able to view my past requests, so that I have a central record of what I've requested and received and so that copyright is less likely to be infringed.

Note: This is a copy of archived request: PENH-I-27907 (also similar to PENH-I-28272).

Primo VE displays all records in brief results for the default Number of Results of 10 records, and then uses an incremental lazy load triggered by scrolling down for Number of results settings of both 25 and 50.

It is well known that even the perception of poor performance for users is a source of complaints, let alone the reality of proven very visible delays that hinder the patron experience while they wait for records to load and that shuffles and moves the display of UI elements around as each piece loads.

This lazy load gives the impression of poor performance, for a discovery environment to apparently not have sufficient resourcing to display even 25 or 50 records, lest display be even more degraded.

It is also noted by comparison that Primo managed by Back Office has lazy load starting only at 50 results, with full record load very quickly at both 10 and 25 results. The expectation of the latest deployment model of Primo VE is that it would offer better performance to legacy models, not worse.

This request is for Ex Libris to improve performance support for Primo VE to remove incremental lazy load at least when the number of results is set to 25 results, and ideally also when it is set to 50 results.

To avoid duplicates when we have both local portfolios and CDI records, we can rely on the "Do not show as Full Text available in CDI even if active in Alma".
Enabling this feature will show in Primo local IZ portfolios, and is very good when local records are rich and CZ records are limited/poor.
Sometimes however CDI records are richer. In such a case we would like to hide IZ local portfolios and show CDI records instead.
Sometimes CDI records at title level are not richer, but chapter/article information are available. In such a case we would like to show local IZ records, and show CDI chapter/article records, while hiding CDI title records.

It would be therefore useful and clearer to replace the "Do not show as Full Text available in CDI even if active in Alma" with a set of checkboxes:

• show local IZ records YES/NO

  • Show related chapter/article records from CDI YES/NO

• show CDI records YES/NO

  • Show related chapter/article records from CDI YES/NO
    

This request is based on an idea ( https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/48828641-replace-do-not-show-as-full-text-available-in-cdi ) and takes into accounts comments added by other customers.

The Research Assistant currently uses only CDI records. We would like to include also local records as sources in this feature. This includes all inventory types Alma-P, Alma-E, Alma-D and external source records, regardless of formats and standards (MARC21, UNIMARC, Dublin Core, XML, etc). The development should take into account metadata within records such as subjects and classifications (LoC, Dewey...), as well as local full text indexed content via options such as Alma-D and external source record full text.

I would like to suggest that Primo supports searchable field codes. I know that Advanced search can target specific fields, but it would be useful to be able to construct a search with field codes in the Primo search box and thus empower stronger Boolean search functionality. In several native article databases it's possible to specify which field to search by writing abbreviations of field codes before the search terms in the search box. For example, AU =jonson, TI = digital photography, JN = journal of advanced nursing and so on. For example, if this request were enabled, one would be able to search for AU:Simpson AND (TI:paper OR SU:paper) in a single search query. Time-saving, as currently it's necessary to repeat complex Boolean queries as exemplified in Use Cases above. Simplification resulting from scanning search results in a single list.

At present, the use of ? and * wildcards is not well supported in conjunction with phrase search using quotation marks. For example "synchronized swim*". This is particularly noted in a blended search of local and CDI records. Since the goal of discovery is to provide a single point of access to all collections, it follows that both indexes should support the same search functionality and operators. This cohesive functionality would not only give users the ability to construct more effective queries, but also make retrieval function a more consistent experience in Primo regardless of record source. This has been confirmed by Ex Libris to be an enhancement request to enhance search functionality in this way for Primo VE and CDI.