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.

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).

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

We propose adding an option to opt out of using Wikidata as a data source for the Person Entity feature in Primo at the institution level and the individual entity level. Use case: We have received complaints that the data provided by Wikidata for the Person Info Card and Person Page is incorrect or misleading for certain individuals. Currently, the only way to address these issues is by editing the Wikidata entries directly, which is not a sustainable solution and is dependent on the timeliness of weekly updates. To provide a recent example: we updated a Wikidata entry to correct the occupation data displayed for an individual. The new data was not reflected in Primo VE for several weeks. Ex Libris advised this may be due to further processing times from the Wikidata servers prior to their call data being updated.

Justification:

1. Updating Wikidata entries directly is not a sustainable solution and is also dependent on the timeliness of weekly updates.

2. It takes several weeks before updated data is reflected in Primo VE.

3. Reliability of Wikidata where everyone can update it.

4. Relying on complaints is not the right approach and can/will lead to reputational damage to the institution.

5. Manual workarounds can lead to technical debt.

Allow institutions to hide or suppress the Person Page and Person Info Card at the individual level.

Use case:
We've received complaints that some person entities display incorrect information on their pages. As updating information directly at the data source (Library of Congress, Wikidata, or Wikipedia) is neither sustainable nor predictable in terms of when data changes will be reflected, we propose providing an option for institutions to exclude specific person entities from being displayed in Primo.

Justification:

1. Updating Wikidata and other data sources entries directly is not a sustainable solution and is not predictable in terms of when data changes will be reflected.

2. It takes several weeks before updated data is reflected in Primo VE.

3. Reliability of Wikidata where everyone can update it.

4. Relying on complaints is not the right approach and can/will lead to reputational damage to the institution.

5. Manual workarounds can lead to technical debt.

Although it is now possible to create local keys for FRBR and DEDUP, mapping for local keys does not support the use of specific subfields, as the default mapping tables do. Currently, local keys support only the fields, like for MARC 21: 009, 09X, 490, 5XX, 69X, and 9XX, but they should also support subfields: a,b,c... etc.

We would like to request an enhancement that would prevent unwanted FRBR/Dedup for works with the same title and publisher but differing creator fields. We discovered this problem with film records that were distributed by the same corporate name (which was indicated in the 700.) I have attached a screenshot of it FRBRizing several distinct films in this way. If I were able to suppress the film distributor as a viable part of the FRBR/Dedup key, it would prevent this. Currently I am using a workaround by removing the offending 700, but this loses an access point-- not ideal.

We are a recent Esploro institution and we are still working out the kinks. However, during this period, we have come across Esploro records showing up in our Primo VE instance and almost always the OpenURL is not formatted correctly so there is no way to access the content. It is leading to frustration by our patrons and confusion by our Library staff. We need to have a way that we can exclude Esploro records but we have yet to be able to figure this out - and from what we have been told, this is currently not possible.

We would like to be able to use Display Logic Rules to hide Purchase Requests for particular resource types. For example, we want to enable the purchase request for ebooks but not ejournals or journal articles or print serials. Purchase requests in Alma (and Rialto) are designed around one-time POLs. Electronic journals and print serials are commonly subscription/continuous POLs which cannot be created from a purchase request, so it does not make sense to offer the Purchase Request option.

It is possible to use General Electronic Services to control this to an extent, but the ‘button’ that appears when the GES is in use has a mandatory hyperlink. We had to create an explanatory page to link to – when we would rather have a customisable message to communicate that ‘requesting is not possible’. Linking out to an FAQ that says “you can’t request” is frustrating for the end user. The GES button also doesn’t look the same as our other buttons, so it gives an ‘ad hoc’ appearance to our Primo display.

Using GES is a clunky workaround and not designed for this purpose, so we would like to see specific Display Logic Rules to hide purchase requests based on resource types.

The Idea Exchange idea (https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/34669447-control-purchase-request-display-in-primo-by-mater) created in 2018 currently (16/12/2024) has 194 votes.

Title: Configure fields included in Primo VE Course Information

Describe the functionality being requested:

We would like to be able to modify the default configuration of Course Information field displayed in the details view of the full record in Primo VE, by adding to or deleting the default elements (Course ID, Department Name, Course Instructor Name) or changing their order.

For example, an institution may want to include only Course ID and Instructor Name but not Department Name. In our case, we want to be able to hide Instructor Names entirely. We sometimes have hundreds of names attached to a single course, most of which are not actual instructors for the course.

Technical Requirements:

Instead of a blanket Course Information field in the Full Record Services > details table of View Configuration, separate Course information out into specific fields for each segment:

It would also be preferable to be able to rearrange the order in which these segments display.

Idea Exchange link: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/36787120-configure-fields-included-in-course-information (currently (18/12/2024) has 164 votes)

With the recent development of the Order It tool available with Rialto, we have realised that for our purposes, we would like to have a similar toll available related to work with Purchase Requests.

Example - Librarians/orderer/user wants to order a book and has found it on the publisher's website/amazon, they can use the bookmark to grab the information and put it into the purchase request form in one click not a series of copy and paste. As our form is behind a link, at point of using the bookmark, it would refer them to the login page giving them access to the form where the form will contain the metadata for the item they wish to place a request for.

Information in the form is less likely to have errors from mistyping and the purchase request form goes in as normal with the information of who is requesting as well as the bib information (ideally with the link of where it’s been grabbed from too)

As this is a tool which requires being added to browsers, I would expect it to be something that library controls giving out the link to install.

The Purchase Request form has multiple minor issues and we feel that it needs to have a general overhaul, with this in mind we've collected together improvements into one CERV request:

• Add the same autofill functionality to the blank Purchase Request form as exists in the Resource Sharing form

• Emulate the features available already in the Rialto Purchase Request form by adding a publication year date picker with 4-digit validation, longer input areas, wider layout, header and footer text/html, and logo upload option

• Permit the placement of the Purchase Request form in records with existing physical and electronic inventory

• Add the option to configure additional local fields that are both label customisable and reportable in analytics (e.g. fund or reporting code, number of copies, link to item/supplier - whatever is desired by the individual library for their own needs).

For the display logic rules to include an ALL/All other function in the rules.

Occasionally, we want to hide something, except when it's the only option available. We can only do this within the Display logic rules by selecting each service or interface individually to add to the list.

Creating the rule in this way makes it very large and unwieldy as well as static, having to go back in repeatedly when a new service or interface becomes available to add it to the extremely large list. By creating an all/all other option it would save time, make it less likely to have errors and dynamic for the library setting it up.

As a user, I would like a research assistant to query and summarize ebook holdings in the same way that it creates summaries and links for articles and book chapters. I understand there may be licensing issues with this, but this already seems possible with the ebook central assistant. Essentially, this is a request for a federated search between those two knowledge bases. If I am a Rapido customer, I should be able to query lendable ebooks using those results.

As a user, I want Research Assistant to query and summarize content in my digitized collections (including showing snippets of non-lendable, but digitized materials, similar to the GoogleBooks 'preview' function (see https://www.google.com/books/edition/The_Theory_and_Practice_of_Group_Psychot/mBq2l4oNMI8C?hl=en&gbpv=1&dq=yalom+psychotherapy&printsec=frontcover as an example). This function seems like it has been affirmed by the US Supreme Court Case Authors Guild vs. Google Inc. (https://en.wikipedia.org/wiki/Authors_Guild,_Inc._v._Google,_Inc.#:~:text=The%20court's%20summary%20of%20its,are%20non%2Dinfringing%20fair%20uses.) and would be a valuable way to expose digitized print materials. If the material is still within copyright, primo should be able to index the full text, and the research assistant should be able to include that digitized text in its results but only show "snippets" of the digitized item.

The Exclude CDI eBooks option on the Define a Custom Search Profile page allows you to remove CDI ebooks from both the filtered and expanded searches in Primo. This is useful for removing duplicate ebook results while keeping book chapter results.

However, because it also removes those results from the expanded results, it diminishes the value of the expanded search for discovery and for initiating ILL requests or Purchase Requests. A more useful function would allow us to apply the "Exclude CDI ebooks" option just to the filtered search and not to the expanded search.

We are not able to use the exclude CDI ebooks functionality in its current form due to its breaking our resource sharing and purchase requesting functionality (where we expand results beyond our collection to reveal content we don’t own/subscribe to which can then be requested).

Use Cases:

A user searching for a known item in the filtered search would get one result for an ebook, rather than multiple duplicative CDI records. At the same time, another user casting a wider net with the expanded search by keyword would get CDI records for books not owned by their library or institution, allowing them to easily initiate an interlibrary loan request or a purchase request. Currently, there is no way to set up the system to allow both.

Justification:

This enhancement would allow more libraries to implement the "Exclude CDI ebooks" option without losing important functionality in other areas. Without this enhancement, the important "Exclude CDI ebooks" option will be underutilised.

Technical Requirements:

Retain the existing ‘exclude CDI ebooks’ functionality for customers who want to keep using it to exclude CDI ebooks everywhere, and add a second option for excluding CDI ebooks only from a filtered search.

Note: This was added as an idea exchange idea by Christine Murray on August 17 2023, and was submitted to NERS 2024 (8820) by Colby College.

Idea Exchange link: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/47112247-allow-exclude-cdi-ebooks-to-apply-only-to-the-fi (the idea has 84 votes as of 07/01/2025)

We add important public notes to portfolios, with access instructions for users. Currently these only display on the full record screen. Users often miss these instructions.

It would improve the user experience to also include these notes in the brief record display, where they have a greater chance of being noticed.
An example would be for resources with restricted concurrent access, reminding users to log off after use, freeing up a place for the next user to access the resource.

One of the most frequent queries our service desks get is that of "how many items can I borrow at a time". At our institution, this differs according to user group - it would be of great value to our users if this information was readily available to them at the "My Library Account" area when signed into PrimoVE.

Enhance the existing solution to support the bulk export of search results for not signed-in users.

For users who do not have an account or for institutions that have Primo VE instances without users (bibliographies, special collections), it should also be possible to use this functionality.

Users will be requested to fill in the target email to send the exported file to.

Users can select to export search results in the following formats: CSV/Excel, RIS or BIBTEX.

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.

Description: Digital Object (DO) titles from an IZ XY are incorrectly appearing in the local search scopes (MyInstitution scope) of other Institution Zones (IZs) views as soon the ShareDigitalResources parameter is activated for the IZ XY. Instead, the desired behavior is for DOs to be included only in the local search scope of their originating IZ and, additionally, to appear in the network-level scope within the views of all other IZs when the according sharing parameter is activated. Therefore, the same logic in discovery should apply like for physical items and digital objects originating from external data sources loaded via discovery import profiles. Notably, Ex Libris already implemented an enhancement for external data sources that allows them to remain unaffected by the ShareDigitalResources parameter (see: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/44489817-sharedigitalresources-parameter-to-allow-individua).

Business Reason: This improvement would have a significant impact. Currently, it is not possible to activate the ShareDigitalResources parameter for our 30 IZs due to its existing behavior explained above. As a result, digital objects are currently only available at the IZ level, and the full potential of Alma-D (later Specto) usage is not being realized.

User story: As an end-user of a smaller Institution Zone (IZ) using its local view, I want to search within the local scope so that I can see results from libraries I can visit within my region without being overwhelmed by not relevant results deriving from other (much bigger) IZs.

Technical requirement: For digital objects, apply the same search logic as for physical items, rather than the logic used for e-resources.

Currently, a site cannot exclude more than three data sources from a Search Profile using Custom Local Data Scopes. Please remove the limitation of three conditions per Custom Local Data Scope or add the option to choose between AND/OR logical operators when adding the Custom Local Data Scopes to a Search Profile. This will allow the creation of views for searching only within the default institutional/Discovery Network scope, excluding multiple data sources.

Knowing there is a potential performance issue in Primo VE with adding more than three conditions to a Custom Local Data Scope, this request suggests choosing the AND logic between scopes that are being added to a Search Profile. Currently, only the OR logic is applied. So, defining a scope for each data source to be excluded and combining those multiple scopes with an AND logic will result in their exclusion from the default search. The relations between AND and OR in the Search Profile’s scopes list will behave according to logical precedence.

The idea is to introduce a new feature: "Favorite Libraries". In the Library Card, patrons could select their favorite library or libraries (regardless of the IZ to which they are affiliated to, in case of a consortium). Consequently, in the Brief Display, this choice would influence the ranking of records, in the GetIt section. The system first displays items from the selected favorite library(ies) on top. In the facet "libraries" where results are sorted by library, the system would display the favorite libraries on top, before other libraries.

We suggest to have the option to create search profiles in Network Zone (Union) views that are displayed after login via a specific IZ. Currently, in NZ views, once logged in (and while being affiliated to an IZ), patrons are displayed a generic search profile. Patrons are confused by the overall concept of NZ and IZ views and don't understand where they are (if they are searching their institution's holdings, or all consortial holdings). This solution would add more granularity to the NZ view and would allow patrons to have an experience that is similar or the same as the one they have in their local IZ view. To help with orientation, customizable elements would also be displayed after log in such as the IZ logos and it would be possible to use customization packages that are read by the browser only after the login via a specific IZ. Patrons do not understand the overall concept and differences between their local IZ view and the NZ view. This solution would add more granularity to the NZ view and improve user experience for patrons.

Currently, Primo offers a "Pay Fine" link and the WPM Education E-Payment System (UK only) both are located in the Library Card only. As with all online stores, it is better for patrons if the payment option is available at the end of the order process when requesting fee-based library services, instead of a payment option in the Library Card. To offer a similar experience to patrons, and a process they recognize from other websites, we suggest developing a payment option that can be displayed (if activated, this would be an opt-in feature) at the moment patrons request services in Primo via the Full Display. For cases where the payment amount is not final or the payment can be done later, the option should also appear next to the request in the Requests List under the Library Card. Patrons are used to paying online at the moment they place their order (or request) on other websites. Having a payment option at the point of order is also more transparent and economical than invoice billing afterwards.

Taylor and Francis adds multiple coverage rows to reflect the different purchasing methods. For example, one line may represent perpetual access while another indicates current access. This is why some coverage statements appear to overlap.

We propose to present only non-overlapping coverage statements to users in Primo.

This enhancement is planned as an upgrade to the current functionality, but there is no set release date as of now. To help expedite this enhancement, the support team suggested to open an idea exchange/enhancement to encourage all users to vote for this idea. The votes can help prioritize this enhancement and contribute to improving user experience.

Currently, the "Service unavailability display message" is only shown at the Journal and article level in Primo. It would be highly beneficial to extend this functionality to the collection level as well. This enhancement would provide users with clearer information about service availability, improving their overall experience and reducing confusion when accessing collections.

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 (with values in $$d, $$e, etc.). Example: https://drive.google.com/file/d/1tSlZtbBYbkR0eDJ6PzBd3obq_x6Q6_46/view?usp=sharing and is attached.

Too much or unnecessary information does not make things clearer for users.

We would like an option that would allow the library to limit the number of fields to display (for example max. three Contributor fields). This limit would be effective for local and CDI data.

Presently if a title has a holdings description in the holdings record 866, or it has a description in an item record, and if the fulfillment rules allow for patron physical requesting, then in addition to item-level request links there will be a "Request other issue" link. The resulting form allows the patron to fill in additional values for chapter, page, volume, issue, part and date. Documentation refers to this as a "Request for a Non-Cataloged Serial Item." However, the link presently appears on non-serial items like this one (though you'd need to be signed in to see the request link).

Given that this link takes you to a form asking for serials-related metadata, we think this link should only appear for serials or articles that meet the other criteria already being used (holdings statement, description, requestable).

Attached is a screenshot of an example affected non-serial item.

It is proposed to enhance Primo VE's capabilities by updating its XML normalization rules options and environment for external source records. Currently, Primo VE supports only XPath 1.0, a standard from 1999, which limits the rule engine's functionality. In contrast, XPath has evolved significantly with versions through to 3.1 in 2017, offering many more robust features. Primo VE’s limitations which would greatly benefit from being addressed by product development in this area include a restricted set of actions and transformations, inability to reference additional data not present in the source, constraints on iterative data processing, and a UI lacking meaningful, actionable error displays. These hinder our ability to handle records effectively, especially compared to the more powerful capabilities offered in Primo environments using the Back Office, which includes extensive validation and transformation rules, along with enhanced regular expression support. This enhancement request seeks to update the normalization rules in Primo VE to align with current standards and technologies, supporting libraries to present their local collections for best possible patron discovery and access experience.

Currently, Primo VE provides only one configurable Pay Link for fines in the My Account area, with no straightforward option to add contextual help links to other sections of Loans, Requests, Fines, Blocks, and Settings.

In contrast, Primo managed by the Back Office allows up to three links for each area, which we've effectively utilised to add direct point-of-need support links to Library Guides, drupal web resources, and integrated payment and membership systems, providing valuable pathways and information on overdue charges, borrowing rules, request options, recalls, renewals, use of search history, and memberships.

This self-help approach is vital to reducing the volume of queries directed to library staff from our 90,000+ patrons.

Given the clear value of such in-context support, it is regrettable that Primo VE has not been developed to include similar functionalities, despite also prior enhancement submissions (#8131 in 2023 and #8785 in 2024).

An attachment is provided to show examples, plus the easy configuration which takes just minutes to set up using Back Office.

This enhancement request seeks to update the configuration options in Primo VE to support libraries to scale-up self-help options by easily adding in-context help links within Primo VE's My account, enhancing both the patron experience and operational efficiency for libraries.

In November 2023, Primo VE introduced the option to specify restricted availability status for external source records. While this enhancement allows us to replicate some functionality from Primo Back Office by changing the availability statement label, it remains limited in scope and lacks alignment with other Primo features. The following gaps need to be addressed to fully support library needs:

• Top-Level Facet Addition: Introduce a corresponding top-level facet with the same label as the availability statement. Currently, restricted records are incorrectly included in the Physical Items or Available Online facets, or both.

• 'View It' Label Adjustment: Allow customization of the 'View It' label for restricted records, enabling libraries to use terms like 'Access' instead of the default label.

• Granular Link Text Options: Expand the normalization rules to offer more granular link text options, increasing from the current single label per restriction type to at least four or five distinct labels.

An attached example illustrates how we currently use in-context help and access information within Primo Back Office, which significantly reduces patron queries by providing clear access information at the point of need.

For example, for our Institutional Repository records we differentiate link text labels based on metadata elements such as dc:identifier linktype, dc:relation, and dc:type, offering up to five different labels. This detailed approach supports a more accurate presentation of restricted access resources.

Previous enhancement requests have been submitted, including #7824 (2022) for manipulating availability statements and Get It functionality by Delivery and Scoping and Links rules, and #7825 (2022) and #8791 (2024) for top-level facets.

This enhancement request aims to further develop Primo VE’s configuration options to address these remaining gaps, enabling libraries to present restricted access external resources accurately and comprehensively.

Make it possible to hide a service, including a General Electronic Service, if Unpaywall access is available (CERV submission recommended by Ex Libris).

Background

We are testing both Unpaywall and Citation Linker currently in the sandbox environment. Citation Linker DOI search and Unpaywall are compatible and work well together except in the following case where we have found Citation Linker is delivering conflicting results to users, related to the activation of Unpaywall.

Key factors:

• Citation Linker (apart from CDI search results) relies on Alma-native records to deliver search results and provide access to content. Items with DOIs are generally articles (CDI content); and books/book chapters which have a presence in Alma.

• Unpaywall operates independently of these constraints. - External data source feeds push content directly into Primo and bypass Alma.

Description:

Our theses are among the resources which feed directly into Primo via OAI-PMH feeds, and bypass Alma entirely. They are discoverable in a Primo search but have accessibility issues in Citation Linker.

They are not accessible in Citation Linker except through the Article DOI search, where Unpaywall uses the DOI to produce a PDF link to the full text.

And Citation Linker, because the theses are not present in CDI and are not present in Alma, incompatibly provides the Interloan link.

This will cause confusion if released into the wild. Yes we could deactivate Unpaywall, but that would mean our theses were entirely beyond the reach of Citation Linker, and we don't think they should be.

We want to be able to construct a rule in General Electronic Services that manages this conflict and enables the Interloan link to be hidden if access is also available through the Unpaywall link.

Direct linking to online resources from the brief results page has been very successful. Unfortunately many people forget that alternative access options may be available on the full record screen, should the preferred link be inoperable for any reason.
It would be very helpful if the brief results page could indicate that such alternatives exist.
We envisage this would be hyperlinked to the details section of the full record screen.
Screenshot attached

Add the "Save query" option to zero-results pages (similar to how it already appears on results pages) for when you want to be notified of expected future results.

For example, you might want an alert for a recently published article not yet in CDI, or an emerging topic that nothing has yet been written about.

This was originally submitted to the Idea Exchange in 2017 by Gary Kaplan as #20144326; it has since been requested by subject librarians at our institution as well.

Currently 'zero results' searches cannot be saved. Developing this functionality will support the monitoring of emerging areas of knowledge and novel subjects, by enabling users to save a query and establish an alert to notify them when relevant content becomes available.

This would be an effective way to extend the use of existing functionality and improve the service.

Syndetics Tables of Contents (TOCs) should be indexed. This enrichment information is valuable and users often look for TOCs (which are hidden in the Unbound service). The TOC indexing is especially important for anthologies and volumes where each chapter is by a different author. There should also be a link in the search results to jump right to the TOC when available. We have a customization that adds a TOC link to the search results, and our user studies show that scholars look for this link, and our analytics show that it gets significant use. Also, when there is no Syndetics content, and there is a MARC 505 field, there should still be a link to the TOC in the search results, and it should go to the MARC 505. Finally, seeing the chapter pagination is valuable when requesting Electronic Document Delivery for book chapters and in Unbound, this information is buried.

"Get It" section item filters need to be visible and not hidden behind an icon. It is not easily apparent how to filter the items and users don't see or recognize the filter icon. Hiding the filters behind the funnel icon requires more clicking and unnecessarily makes it more difficult for users to find items. Also, the funnel icon appears even when there is nothing to filter. There should be no filter icon unless at least one of the items has an Item Description.

Primo should make use of Linked Data to provide a way for users to see an ordered list of works based on the controlled headings in the bib records. When doing research involving works by prolific authors or "great" works like the BIble, Koran, etc., newer discovery interfaces do not provide a mechanism for the user to see an orderly and concise arrangement of the entire scope of resources held by the library, with sufficient elements in the list entry to identify items of interest. In the traditional OPAC, a browse feature existed that allowed users to see a highly ordered list of what works that were held by the library, and see the details of the work in the list entry (uniform title, date, musical key, etc.). For example, a user could navigate piano concertos by Mozart and see them in the logical order with composition number and musical key. This information is painstakingly cataloged in controlled headings that are not being well-utilized by discovery systems. Many works are contained in anthologies or compilations, making it additionally difficult for a user to find all instances of an item they want. Use of facets and indexes for these authors/works is often not helpful, because the facets take a controlled heading apart by reading only some elements, and you no longer see the right context.

Use case: a user is looking for Bartok's Violin Concerto No. 2. They search for author "Bela Bartok" and title "Violin concerto no. 2." In the first few results, they see a musical recording compilation with Prokofiev's "Violin concerto no. 2" and Bartok's "Rhapsody no 2." Neither of these is the work they are looking for. The result was retrieved because it has title "Violin concerto no. 2" by composer Prokofiev, and a different work by Bartok. Because the Prokofiev title was in the title index for this disc, and Bartok was in the author index for this disc, the record appeared in the search result. There is no mechanism that takes advantage of the controlled heading added by the cataloger to keep the elements in context: 700 |a Bartók, Béla, |d 1881-1945. |t Concertos, |m violin, orchestra, |n no. 2.

Showing only transliterated fields can make a title or term unrecognizable to a reader of the original language, who knows the vernacular script and not the Anglo-American-centric Latin transliteration. Non-Latin scripts are extremely important in describing and discovering collections and providing access to non-Western resources. Non-Latin scripts from data sources such as HathiTrust and Center for Research Libraries are not displaying in CDI. In contrast, when there is non-Latin in an *article* record in CDI, the non-Latin generally displays without a problem, but not for data sources that presumably supply MARC source data. For example, OCLC 502898363 from HathiTrust should display as 硤川 詩鈔, but instead displays as 'Xia chuan shi chao.' There are 5 fields with non-Latin script in that HathiTrust MARC record, and none of them display in CDI.

Public licenses can be viewed in Primo VE's electronic holdings information area,

But public licenses are not displayed in the electronic holdings display area of other institutions.

I would like to be able to display public licenses from other institutions within the consortium on my own institution's Primo VE.

Without this function, I think that being able to view information on other institutions' electronic holdings would have little effect.

Detailed information is attached.Here is a related Idea Exchange.

https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/47399399-reference-to-public-licenses-of-other-institutions

We would like the ability to display BOTH the 86X summary field from the Holdings Record AND the system-generated summary ("from... until...") statement in the Location list.

By default, Primo VE will display EITHER a system-generated summary in the form of "from... until..." based on the entries in the Enumeration and Chronology fields in the Item Record/s attached to a holding OR a Holdings Record's 86X summary field, when available.

Primo should provide the ability to configure redirects for Collection Discovery items, particularly when migrating to VE. It is already possible to add redirects using the Deep-Link mapping table, so this functionality should be extended to route incoming /primo-explore/ requests to /discover/ as Libraries potentially have many links to Alms-D collections embedded in institutional websites/VLE environments etc. and it is unacceptable for these to simply break when switching to VE.

This Idea Exchange entry is related https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/48137414-ability-to-create-url-redirects-for-deleted-collec but refers to deleted collections.

Edits to a holdings record in Alma trigger reindexing of the bibliographic record in PrimoVE. However, if a holdings record is deleted or supressed this does not trigger reindexing which can cause confusion. For example, libraries A, B, and C have holdings on the record for Title X in Alma. Library B deletes their only holding record, but Title X still appears in the search profile for Library B in PrimoVE because reindexing has not occurred.

Deletion and suppression of holdings records should trigger reindexing of the record in in PrimoVE in the same way as edits to holdings records.

The separation of the 2 vocabularies in Browse Search forces users to check 2 separate browses to see all headings on a topic. This issue would likely be a problem for Linked Search Subject Cards as well. For example, "Michigan--Antiquities" is in the LCSH browse, but "Michigan--Antiquities--Bibliography" is in the LCNAMES for 651. There should be a single subject browse that contains both LCSH and LC names for 651. The arcane catalgoing rules around "free-floating" subdivisions" are part of the reason these vocabularies are separate in LC and on the Alma side, but Primo users shouldn't have to check 2 browses and there needs to be a better solution, otherwise users are not finding relevant resources.

FULLER EXAMPLE

In LCSH browse you see:

• Michigan--Antiquities;

• Michigan--Biography;

• Michigan--Guidebooks;

But in LC Names for 651 you see:

• Michigan;

• Michigan--Antiquities--Bibliography;

• Michigan--Antiquities--Periodicals;

• Michigan--Gazeteers;

What we want to see is a single browse with both vocabs:

• Michigan;

• Michigan--Antiquities;

• Michigan--Antiquities--Bibliography;

• Michigan--Antiquities--Periodicals;

• Michigan--Biography;

• Michigan--Gazeteers;

• Michigan--Guidebooks;

MORE BACKGROUND

In LC practice, some subdivided geographic headings are established LCSH authorities, not LC Name authorities. Only the un-subdivided name is included in LC Names. Subdivided names are included in LCSH. Also, there is a list of "free-floating subdivisions" that can be used under place names in the Subject Headings Manual, H 1140. Most of these are not established in LCSH under individual places, unless a further subdivision that is specific to a place needs to be established. For example, $x Abstracting and indexing is a valid subdivision in the list, but United States" Abstracting and indexing is not in LCSH. On the other hand, $x History is a free floating subdivision, but United States" History is in LCSH because it is needed as part of the structure to add specific subdivisions, e.g. United States" History" Civil War, 1861-1865. Sometimes a heading is in LCSH because cross references are needed for that combination. For example, $x National Guard is a free floating subdivision, but United States" National Guard is in LCSH because it has references from National Guard (United States) and United States" Organized militia, 1903-1916.

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.

Currently Public Notes for Database-type collections can only be placed on the record for the collection itself, and they are not displayed on individual content. But the info we communicate in Public Notes is most often needed for accessing the individual content. So we can use Public Notes to help our users with Full Text and Selective type collections that include portfolios, where the notes can be displayed at at the individual portfolio level or at the collection/service level. When public notes are added to a database-type collection, these notes should display not only at the database record level in Primo but also at the article-level for content held within these collections. The same functionality for Public Notes should be applied for all types of content.

Users may have multiple addresses in Alma. The Personal Details tab within My Account only can display one address, the preferred address. The display of multiple addresses should be configurable. Users often have multiple addresses (home, work etc.). When users are unable to review all of their addresses, one or more addresses may be incorrect, consequently going undetected by the user. When selecting addresses for Personal Delivery, items may be sent to an incorrect address. This results in poor customer service for the user and losses for the library. Primo should allow the display of multiple addresses in the Personal Details tab within my Account to give users greater awareness and ownership of the details on file for them.

Publication Date is not an adequate indicator for researchers who need to consider currency when searching for journal/serial publications, since the publication date does not consider the ongoing nature or publication nor local coverage and holdings. For journal/serial publications, the Publication Date filter reflects the publication dates of the title as a whole, but researchers also – and more relevantly – need to determine the dates of coverage within an institution’s holdings. An additional option for searching or faceting on coverage dates, including "open" for currently received is needed. Users should be able to add "currency" and "coverage dates" to searches in Primo, for both electronic and physical materials.

Coverage summary by year can be displayed in Primo results list for electronic journals; this summary is also needed for physical journals. The lack of equivalent coverage summaries for physically held journals causes researchers to overlook or misinterpret a library's physical holdings. Summary holdings for physically held journals should display in Primo results lists as they do for electronic journals. The holdings could be taken from the Summary Holdings field of the Holdings record in Alma. In 2021 there was introduced the option to display coverage summary by year in its availability statement in the results on the Library Search and Journal Search pages for electronic journals. This functionality should be extended to include physical journals with holdings.

We could provide a better research experience for our broad range of users if they were able to opt in and out of our system defaults to create a personalized search interface that better suits their unique research needs. Currently, institutions set a single set of default Primo search settings for all users, including the default search profile, FRBR/dedup settings, "Expand my results", "Search in full text", facet value sorting, and so on. Users can change some of these settings within a search session, but their selections are not sticky. When the session is reset, the institutional defaults are re-applied and they must re-create their ideal search environment within every session. Being able to select and save their own search defaults would greatly improve the user experience and enable better institutional service to a wider range of user needs.

We can create multiple types of Resource Recommenders, but if multiple items within a particular type match the tags a user searches for, multiple items are returned from a single Recommender and some Recommenders are hidden. We would like to be able to highlight one result from each matching Recommender. We would also like the option of displaying 4 instead of 3 entries when there are 4 or more suggested resources.

Many institutions would like to enable tagging functionality but choose not to because of the inability to prevent inappropriate tags from being displayed in Primo. We can review tags and remove them after a user has assigned them, but this is not sufficient. The tagging functionality would be more usable if we could either moderate the tags and approve them before public display or if we could opt to allow tag creation and display by some user groups (such as Faculty and Staff) but not all user groups.

The Views List within Discovery Configuration in Alma includes Code, Name, and Description. It would be very helpful if both Creation Date and Last Update could be included in this display to enable better tracking and management of different views and configuration updates, especially when new features are introduced that require manual update in all individual views.

Currently the sorting of facet values is set by the institution and cannot be changed by the user. However, it would often be helpful for the user to select a different sort option. In addition to being able to toggle between A-Z and number of records, the user should have the ability to toggle the sort for each between ascending and descending. This functionality is very common in many other catalogs and databases.

Currently the Resource Sharing Request form is fixed/non-customisable in the options available, e.g. format everything is available Digital or Print. However, for some circumstances we need to hide the options that don't apply to the request being made (see use case below) Given that conditionality/logic toggle is in the form for the chapter fields, this would is an additional application of the existing functionality in Primo forms, but that we could control.

Use Cases: Where we can only provide a resource type in one way (print or electronic) we want the selection of resource limits the format type appearing on the form AND give us the option to make a default too. We currently cannot offer whole book Resource Sharing requests in electronic format, only print. If someone requested an entire book as an ebook, we have to contact them and give them other options, alter the request at that point. Extra confusion and frustration for user. Extra work for staff. We need the ability to customise what is available on the form based on selection. e.g. Book AND Chapter not ticked, only the print option appears. We also would like for conditionality to be available for other elements are well, e.g. should we be able to provide eBooks for resource sharing again, we would like to be able to alter the default format (digital or print) based on the resource type being requested (e.g. whole book = default print, article = default digital)

Justification: Current rigidity of the form options currently causing confusion and extra work.

Keywords: Resource Sharing; Primo Forms; Forms; Conditionality; logic functions; toggle logic; Requests; Document Supply; Inter-library Loans

This request was submitted previously as NERS 8823.

We request the ability to display search profiles, scopes, and slots separately and selectively in Simple and Advanced Search. Today, any search profile added to a search configuration automatically appears in both Simple and Advanced Search together; it is not possible to configure them separately. We would like the option to display the profiles, scopes, and slots in Simple Search only, or Advanced Search only, or both. We request this at all levels of search profile/scope/slot configuration.

We have developed scopes based on special collections. Given the nature of the content, it would be beneficial to only have scopes available in Advanced Search and not in our main Simple Search bar. We also have some functionality we developed that only works in a 'library only' search profile. However, we do not want to add scoped searching into our main Simple Search bar but only Advanced. If this feature were added, with the granularity to allow scopes ONLY in Advanced or Simple Search, it would allow greater functionality and options to libraries. This would allow users to perform a more complex search and with scopes applied (e.g. title and author and date and scope in one go). This enhancement would provide additional parity between the two search options and allow enhanced functionality and options for libraries.

Previous submitted in NERS 8821

Add a 404 page which shows the main menu and which is customizable, in analogy to the "zero records found" page.
This is especially necessary for a mistyped view name, which just leads to an empty page with a spinner.

From https://ideas.exlibrisgroup.com/users/101581440-ulrich-leodolter:
"In the background Angular is unable to fetch the configuration URL /primo_library/libweb/webservices/rest/v1/configuration/PRIMA which is answered by an HTTP 406 error from the server.

To the end user it's completely unclear where the problem is located. Did she/he make a mistake, or is there a problem on the server?

I would suggest providing at least a generic error page (View Code not found) and respond by HTTP 404 or 406 to the client. This is also important for search engine crawlers if there are any outdated permalinks on websites.

For multitenant and local installations it would be great if this can be customized at view level.

We want to display Attribution in our short title display in Primo VE.
But when we do that, the titles coming from CDI don't show an author.
Quote from Ex Libris, January 2025: "Unfortunately, displaying the Attribution (Statement of Responsibility – 245$c) as part of the title is not supported at this time. Implementing such functionality would require submitting an enhancement idea for community voting."

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.

At present, the use of wildcards or truncation is not supported when searching phrases in CDI (e.g., "synchronized swim*"). It is worth noting that this functionality is supported when searching local records. It just does not work when searching CDI or using a blended scope. Since the goal of discovery is to provide a single point of access to local and remote collections, it follows that both indexes should support the same search functionality and operators. Standardizing this functionality would not only give users the ability to construct more effective queries, but also make retrieval function more consistently in Primo regardless of record source.

According to the documentation below, Primo customers can choose to exclude journals from direct linking since, unlike articles, users must first choose the platform that offers the best coverage for the content they seek. However, this setting only applies to portfolios where electronic material type is set to "Journal." Newspapers and magazines are similar to journals in that users must be able to review coverage options before selecting a platform. And yet there is no option to exclude newspapers and magazines from direct linking.

In addition to being counter-intuitive, this policy also leads to inconsistent results depending on how electronic material type is defined in the CZ where some newspapers are set to "Newspaper" while others are set to "Journal". And because this information is not readily visible to the end user, they have no idea why direct linking is applied to some newspapers but not others. To ensure consistency, customers should have the option to exclude all serial publications (not just journals) from direct linking.

https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/080Configuring_Delivery_Services_for_Primo_VE/Configuring_Discovery_Interface_Display_Logic_for_Primo_VE#Enabling_Direct_Linking

Develop a method for filtering out book chapters with no meaningful scholarly content from CDI (e.g., title page, copyright, acknowledgements, etc.). These tend to glut up search results and confuse library patrons.

For example (screenshots attached):

Chapter Title = Frontmatter
https://rutgers.primo.exlibrisgroup.com/discovery/search?query=title,begins_with,frontmatter,AND&tab=Everything_except_research&search_scope=MyInst_and_CI_2&sortby=title&vid=01RUT_INST:01RUT&lang=en&mode=advanced&offset=0&facet=rtype,include,book_chapters,lk

Chapter Title = Title page
https://rutgers.primo.exlibrisgroup.com/discovery/search?query=title,begins_with,title%20page,AND&tab=Everything_except_research&search_scope=MyInst_and_CI_2&sortby=title&vid=01RUT_INST:01RUT&lang=en&mode=advanced&offset=0&facet=rtype,include,book_chapters,lk

Chapter Title = Copyright
https://rutgers.primo.exlibrisgroup.com/discovery/search?query=title,begins_with,copyright,AND&tab=Everything_except_research&search_scope=MyInst_and_CI_2&sortby=title&vid=01RUT_INST:01RUT&lang=en&mode=advanced&offset=0&facet=rtype,include,book_chapters,lk

Chapter Title = Acknowledgements
https://rutgers.primo.exlibrisgroup.com/discovery/search?query=title,begins_with,acknowledgements,AND&tab=Everything_except_research&search_scope=MyInst_and_CI_2&sortby=title&vid=01RUT_INST:01RUT&lang=en&mode=advanced&offset=0&facet=rtype,include,book_chapters,lk

Chapter Title = Backmatter
https://rutgers.primo.exlibrisgroup.com/discovery/search?query=title,begins_with,backmatter,AND&tab=Everything_except_research&search_scope=MyInst_and_CI_2&sortby=title&vid=01RUT_INST:01RUT&lang=en&mode=advanced&offset=0&facet=rtype,include,book_chapters,lk

Alma offers institutions the ability to create collections to facilitate discovery and access to groups of related resources. In addition to being displayed on the Collections Lobby page, collections can be made accessible via direct links on websites, research guides, or course syllabi.

However, when a collection is deleted, suppressed, recreated, or migrated from Primo, any links or bookmarks to that collection are broken.

To avoid this, customers should have the ability to configure redirects for collection page URLs that can be used to route visitors to another page. It is suggested that an expansion of the existing "Primo Deep-Link Re-Direct Configuration" table could be used for this purpose.

Related Idea Exchange submissions: https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/48137414-ability-to-create-url-redirects-for-deleted-collec

When setting up a Primo Analytics report for actions on Collection Discovery collections via the Primo Customized Values Usage subject area, the only option available is to display each of the Collections by name.

We would like Analytics to be updated such that Collection Discovery usage can be reported by Collection ID as this represents a unique identifier for each Collection and Sub-collection and remains constant even if the Collection Name is changed.

We have a large number of Collections and Sub-collections active, and within these there are some that have the same name - where this is the case, Analytics seems to be combining the usage figures across the similarly named collections rather than reporting usage on each collection individually.

Additionally, where we have changed the name of a collection, this has resulted in the usage for a single collection being reported across two separate values in the Analytics report.

Reporting usage against the Collection ID would resolve both these issues, however we would request that the Name be retained for ease of identification of the collections included in the report.

Categories in journal search are very detailed and some have three levels. Based on the library collection, some third-level categories return few results, in some cases even a single record.

Each institution should have the ability to decide which subcategories to enable (yes/no) via Alma>Discovery configuration.

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.

Currently, the basic search and advanced search results provides journal, database, and newspaper records the ability to broaden the search by using lateral links. When the same records are displayed on the Journal Search, Database Search, and Newspaper Search pages, they do not have lateral links. This means there is no way to find more from the listed authors, subjects, related titles, etc. Please add lateral links to these pages for all fields available as in the basic search and advanced search. For each of the above search pages, the library should be able to configure the target Search Profile (Primo VE) and Search Scope (Primo).

[Request previously submitted as NERS 8757]

Currently, journals and e-journals records must have MARC21 050 $$a with Library of Congress classification notation in order to be included in the list of categories in the Journal Search.

Since UNIMARC is a supported format in Primo VE, it would be useful if the "Creates Journal Categories File" job could also work with the UNIMARC 680 field, subfield $$a.

Enhancement request previously submitted in 2024 as #8758.

Journal Search, as it is currently structured, does not help users discover and select from thousands of journals. Navigation with categories is helpful, but there are other channels for navigation and discovery. It would be very useful to have facets on the page that would help users filter (top level, date, language, subject, etc.).

Enhancement request previously submitted in 2024 as #8759.

We would like to be able to login as users to support them. Sometimes it happens that they ask for help because they cannot do an operation and if we could login as them, we could understand if the problem depends on not having enough privileges or on a human error. This proposal recalls the 2022 NERS request #7608 “Enable User Administrator role with "login/view as user" function”. Our goal is to improve our abilities to assist users in troubleshooting and role management. When troubleshooting user account issues, admins (e.g. library managers; user managers; user administrator) would be able to log into Primo as the user experiencing the problem. Many other systems offer this type of feature to allow administrators the ability to troubleshoot when confirming workflows and privileges when new roles, scopes, and parameters are added. The requested functionality would allow us to view the same data that we already see within the current workflow (currently we are fully GDPR compliant). Therefore, this “login as” functionality would not impact on the user’s privacy more than the current workflow does. This “login as” functionality would allow only to view user’s data, not to act on their behalf.

Request already submitted as NERS 8917.

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.

Leveraging Dewey classifications from the Web Dewey (https://entities.oclc.org/worldcat/ddc/) The Marc21 field 082 now allows the URI to be recorded in subfield $1. We would like to leverage the classifications for searching and displaying the corresponding label, as well as to generate facets in the Primo discovery interface. The json.ld file for each 'concept' entity provides forms in multiple languages and the URIs of the broader term and specific terms. Utilizing the linked data from the DDC Web would be a significant added value for end users. It also helps avoid complex local developments for a feature that would benefit the community.

Currently, the normalization rules for Discovery Import Profiles only support XPath 1.0, which doesn't allow for regex and tokenization. Support the latest version.This would allow for increased granularity and control over normalization rules for OAI-PMH records

Allow alphabetical reverse "sort by" options for author and title. Alternatively, if reversing the sort is too computationally expensive, an option in the pagination area to jump to the end of the results and go backward could fill this need.

The current pagination makes it extremely difficult to find an item in the results set with a late-alphabet title/author because there's no rapid way to jump to the end of the list.

The workflow for adding or revising fields within the Full Record Details would be quicker, more efficient, and less likely to cause errors if it were possible to reorder by drag and drop or another means than the current "move up/down" by a single row at a time. Some configuration tables in Alma support drag and drop (Display Logic Rules) or the ability to place "at/before" the top, bottom, or any item in the list (Create and Manage Collections). Enabling these improved methods for placing and reordering the Details within the Full Record for public display would greatly increase and improve Alma usability and staff productivity. It would also benefit end users by ensuring that important additions and revisions can be made in a very timely and accurate fashion.

Within Request and Resource Sharing forms, users must select a delivery address, which may include multiple Personal Delivery options, such as home or work. Users may have multiple addresses on file so it is helpful to offer them the choice of personal delivery locations. However, unfortunately, users do not always know which address they have affiliated with the different options. This means that it is easy for them to be confused by the form options and select the wrong address for delivery. It would alleviate much confusion and be extremely helpful to the user if the address affiliated with the personal delivery location were also displayed within the form, so they always know exactly where they are directing delivery.

Institutions can enable "Display to Public" for the user address with the Hold and Booking Request form, but there is no such option for the Resource Sharing Request form. Additionally, the "Display to Public" configuration allows users to add and modify address details on the Request form, which is not tenable for institutions that load user addresses and other data from external sources. For these institutions, the data needs to be changed within the source system; any changes in Primo or Alma would be overwritten with the next data load. So we would like to display the addresses to the user but not allow editing.

We would like the address details to be displayed in "read-only" mode to users in all request forms -- including Hold and Booking and Resource Sharing -- in which personal delivery selection is an option.

Situation - A lot of our staff add items to Leganto via Primo’s Reading List button. However, when they have a lot of lists, it is difficult to scroll the entire set of their lists to find the one they want.

Solution - We would like a search option for the ‘Please select a list’ drop down so that staff can search for the list they want to add the citation to. And it would be great if it could retain the last one that user has picked, as staff will usually be creating one list at a time.

Situation - Currently we can get statistics from Primo Analytics for whether items have been clicked etc. However, it is not currently possible to separate these statistics by what source the record was imported from. As a library, we would want different statistics for whether the record is from D-Space or electronic legal deposit or Archive Space etc.

Solution - Add a column of information to Primo Analytics to define the source of the record so that the results can be filtered to show what sources users are accessing.

Researchers and students are often seeking the most recent studies to ensure their work is based on the latest information. Displaying the most recent holdings at the top aligns with their needs and helps them to find the information they are seeking faster.

This enhancement requests to add an additional configuration option to the Online Services Order to allow us to preference the most recent holdings, which would be useful because it would place the most recent research at the top of the view online results in order from the most current (often unembargoed) holdings to our oldest, least current access options.

Attachment caption:

A search for the journal, Stem cells translational medicine. PubMed Central's link with the holdings listed as, "Available from 2012 volume 1." holds the unembargoed and most current results, but it is now in the middle of the list, and not at the top.

We would like to use the LOD Person Entity features in Primo VE to provide better highlight of and attention to the local authors affiliated with our institution, such as faculty authors. We already ensure the creation of authorized headings in the Library of Congress Name Authority File, so the local authors do have Person Pages and Cards utilizing their basic bibliographic identity details from LCNAF. However, Person Pages and Cards can be greatly enriched by the inclusion of Wikidata elements that provide eye-catching and user-pleasing enhancements, such as author photos and biographies -– but not all authors meet the notability requirements of Wikidata/Wikipedia (c.f. https://en.wikipedia.org/wiki/Wikipedia:Notability_(academics)). We want to be able to provide this enrichment for authors who are not included in Wikidata. A wealth of information about local authors is often available on university websites, databases, and similar platforms: photos, affiliations, disciplines, research areas, biographical statements, and so on. We would like to use these sources as an alternative to Wikidata to enrich the Person Pages and Cards. We could ensure that the local source data is presented within whatever fields and formatting would be necessary to make such an alternative work. For example, we could use a template for entry, perhaps similar to the Resource Recommender entry templates.

Integrating NoodleTools with Ex Libris Primo VE would streamline the research process for users by seamlessly connecting citation management and library resource discovery. This integration would allow users to easily export citation information from Primo VE into NoodleTools, a citation management platform often used in colleges, aiding in the creation of accurate bibliographies and saving time on manual citation entry. Overall, this enhancement would be in line with the Exlibris commitment to continuing to improve the user discovery experience.

At large universities, students and other users are active at all hours of the day, and often work according to individual and irregular schedules. Additionally, many users are using the library platform in widely different timezones from the timezone in which the cloud platform is situated. Consequently, providing a useful, informative and customizable 'error' page during periodic system down-times on the ExLibris cloud platform would be a valuable service to our users, who will naturally be unfamiliar with the system maintenance schedules. Ideally, providing a mechanism to configure a custom 'System Down' page for each unique institution/view would allow us to provide a more seamless and clear user experience during these off-hours maintenance activities.

The primary configuration option for adding appropriately prominent additional links in Primo VE records is via General Electronic Services.

We use these links to “scale up” our services, by enabling our patrons to self-help through providing pathways to helpful information at the point of need in our discovery layer.

For example, we have created a Library Guide on correctly citing our special collections in our Archival Management System with nuances which automatic Citation generation tools may struggle to match, and it is most useful to our patrons for them to see that this guide is available when they are discovering and accessing that resource via Primo VE.

As well as being helpful and supportive for our patrons, adding such links is a sustainable strategic practice for our Library, in recognising the smaller number of Library staff versus 90,000+ patrons, and the level of personal support we can reasonably provide one-on-one.

While initially seeming rich with options, in practice there are significant limitations with configuring these links in Primo VE, particularly with Service Availability Rules.

This request is to expand the options for adding links in Primo VE in order to meet a broader range of use cases. The request applies to both Alma and external data sources regardless of record format, import, or normalisation method, as we provide a holistic blended service to our patrons regardless of the source system.

Use case examples needing to be met by this development include:

• Add a link to all records in a data source

• Add a link to all records which have a dc:identifier with string xxx or yyy or dc:relation with string xxx or yyy, but not zzz

• Add a link to all records which have a resource type (as the type of record in display and facet visible to patrons) of xxx or yyy, but not zzz

Our Alumni and other limited access users face significant frustration when they encounter Central Discovery Index (CDI) records in Primo stating ‘Full text available’ when they do not actually have online access to these resources on the source platform due to vendor contract limits.

We would like to improve the personalised patron experience in Primo for these members, with accurate availability information for CDI records by the patron’s logged in user group and CDI Electronic Collections accessible to the limited access users.

Proposed outcome summary: Modify CDI search results so that limited access user groups only see full-text availability for resources they can access, while non-accessible resources remain in expanded search with appropriate labels.

Proposed outcome details:

• Filtered search will only contain CDI records available in full text to the limited access user group, with corresponding ‘full text’ availability statement, ‘Available online’ facet, and accessible only platform specific View it links.

• Expanded search will contain all CDI records, including those not available online to the limited access user group, with corresponding ‘no full text’ availability statement for only these limited access members.

• CDI Quicklinks will not display when the associated platforms are not available to the limited access user group.

• Open Access links in both View it and Unpaywall features will not change, and continue to display as usual if configured separately.

The following are NOT acceptable outcomes:

• Completely excluding non-accessible CDI records from search results for limited access user groups.

• Returning CDI records in filtered search stating ‘full text’ availability information, and then dynamically changing this information to ‘no full text’ when a limited access user group patron attempts to access the resource, such as by opening the record.

Note: It has been confirmed with Ex Libris in January 2025 that the proposed outcome is not currently supported in Primo, including via either ‘Restricted User Groups’ or ‘Restricted Search Groups’ (07830538).

Primo VE requires a case to be opened to request discovery related indexing for changes to take effect comprehensively across all Alma records, such as for search and facet rules and FRBR / DEDUP adjustments.

This is a significant downgrade from the autonomy enjoyed by sites using Primo managed by Back Office, with the ability in that environment to initiate renormalisation as desired by the 'No harvesting – Update Data Source' Pipe and with use of Force FRBR and Force DEDUP checkboxes to reset groups.

If Ex Libris has concerns regarding performance in Primo VE as a result, then it is reasonable to include associated safeguards, such as running the job slower in-background, or by conditions such as limit of once a month, or only to start in specific designated 'quiet' times of the day or week. Ideally, Ex Libris would commit appropriate resources to developing Primo VE so that it can handle the reasonable expectations of libraries to be able to update their local data.

It would not be acceptable to limit this job to only small sets of records, as is currently possible with limited scope Recalculate Resource Types jobs, as very often many changes will be made across a range of fields and records, and update is needed holistically.

Currently, Primo VE “Normalization (Discovery)” rules for external source records are available beyond Primo VE roles.

This is problematic as not in alignment with expected design of fit-for-purpose match for role-based access privileges on the platform, is not even consistent given the access is only for external source record rules, and is inappropriate from a risk mitigation perspective of ability to significantly impact the Primo discovery environment.

This issue was identified and queried in case 07083886, as an assumed defect due to absence of any documentation that the access observed in the platform was expected.

In contrast, the documentation published and unchanged on this topic for many years clearly specified access only by a specific configuration pathway that is only available to users with a Primo VE Discovery role.

Unfortunately Ex Libris deemed this to be “by design”, and simply changed the documentation to match the current behaviour, as opposed to responding to the concerns raised and agreeing that it was a defect that needed to be fixed.

This request is to change development in this area to access to “Normalization (Discovery)” rules for external source records to only users with the Discovery Administrator role.

As this change could potentially be disruptive to existing customers, an acceptable solution would be as available for other roles, for customers to have the option to open a case to request for enabling or disabling of the corresponding privilege.

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.

Primo VE currently offers no configuration options for Browse Search and Virtual Browse by browse normalization rules. This is possible in Primo managed by Back Office, with such adjustments made to improve the feature including removing low value subjects such as 648 chronological term, 655 genre, and 650 when bisacsh; eliminating records with incomplete call numbers such as those with only the main class and data with no browse meaning such as "ISSN RECORD" from Community Zone records; adjusting for local practices in 090; and inclusion of some non-Alma data source records for specific browse search indexes only and with normalization to remove national regulatory codes. Such configuration is important to our site as a valued user service, with Virtual Browse averaging several hundred clicks per day. In contrast, it is notable to observe that Primo VE sites appear to have disabled both local browse features. This is a feature alignment issue hindering ability to switch from BO to VE.

This is a duplicate of archived item PENH-I-28218 (re-added as this functionality is still missing from Primo VE).

Note: This is a duplicate of Archived item PENH-I-28276 (Archived PENH-I-28120 is similar). I've re-added it as the functionality still hasn't been delivered. We would like to be able to modify the default configuration of Course Information field displayed in the details view of the full record in Primo VE, adding to or deleting the default elements (Course ID, Department Name, Course Instructor Name) or changing their order. For example, an institution may want to include only Course ID and Instructor Name but not Department Name here. This is not currently possible.Idea Exchange https://ideas.exlibrisgroup.com/forums/308176-primo/suggestions/36787120-configure-fields-included-in-course-information currently has 164 votes

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).