Primo
Your feedback matters to us. Help us improve Primo by telling us what you’d like to see using the message areas below. You can also can support something already posted.
We would love to be able to respond to every idea that is submitted, but this is not feasible. We are, however, committed to responding to the most popular ideas—those that have received the most points.
For more information please review our FAQ and guidelines. Thank you.
- or
3 results found
-
Include the item barcode as part of the data published from Alma to Primo in the AVA field to improve item search in Primo
Request for Alma item barcode be included in the data that is published to Primo as part of the Alma publishing functionality to enable barcode searchability in the Primo keyword search. We have discovered that items migrated from our previous ILS do contain the item barcode(s) in the MARC 945 $$i and is written to the search:general field of the PNX. As such, those items are keyword searchable via their barcode in Primo. However, for items created in Alma, the item barcode is not written to the bib record and is therefore not searchable in Primo. Adding the item barcode manually to the bib 945$$i for each item as part of our processing is not a viable alternative.
We would like an enhancement to Alma publishing that would add the item barcode to the data published in the "AVA" field. This functionality would improve workflow for staff when they need to search a record in Primo without having to navigate out of the items screen in Alma to retrieve the OCLC number, the MMSID or the ISBN, or to pull up the record in Primo when the book is in-hand without needing to key in the title or ISBN.
Examples of migrated records with the item barcode in the 945 $$i:
http://alliance-primo.hosted.exlibrisgroup.com/CC:cc_alma:CP71153242760001
http://alliance-primo.hosted.exlibrisgroup.com/CC:cc_alma:CP71188416360001451Request for Alma item barcode be included in the data that is published to Primo as part of the Alma publishing functionality to enable barcode searchability in the Primo keyword search. We have discovered that items migrated from our previous ILS do contain the item barcode(s) in the MARC 945 $$i and is written to the search:general field of the PNX. As such, those items are keyword searchable via their barcode in Primo. However, for items created in Alma, the item barcode is not written to the bib record and is therefore not searchable in Primo. Adding the item barcode…
465 votes -
Less duplicate records in Primo Central Index results
Primo Central grouping is based on the existing FRBR workflow, including the grouping process at the database level (the way the Search engine handles grouping) and the Front End functionality. It is used to prevent duplicate records in the results list.
Unfortunately, many records are not added to FRBR groups because the system considers the metadata are not rich enough. With the increase of records provided by (Open Access) aggregators and repositories, the number of duplicate records will certainly not decrease.
Could Ex Libris improve the FRBR workflow for Primo Central records in order to reduce the number of duplicate results and consolidate the FRBR groups?
Examples of duplicate records:
Accuracy of prediction of gene content in large animal populations and its use for candidate gene detection and genetic evaluation
3 results (2 FRBR groups):
- TNproquest195858157 and TNfaoagrisUS201300875183
- TNcrossref10.3168/jds.2007-0231, TNscopus2-s2.0-42449094585, TNsciversesciencedirectelsevierS0022-0302(08)71293-1, TNmedline18349258
- TNorbi2268/23076Linguistic symbiosis between event loop actors and threads
2 results (1 FRBR group):
- TNsciversesciencedirectelsevierS1477-8424(08)00024-9
- TNscopus2-s2.0-51649125887 and TNcrossref10.1016/j.cl.2008.06.005Efficient control of transient wave forms to prevent spreading depolarizations
2 results (1 FRBR group):
- TNarxiv0705.3398
- TNscopus2-s2.0-39649117125, TNsciversesciencedirectelsevierS0022-5193(07)00579-6, TNcrossref10.1016/j.jtbi.2007.11.019, TNmedline18177900Le traitement de la modalité épistémique dans les traductions françaises de On the Origin of Species de Charles Darwin
3 results:
- TNerudit1038687ar
- TNscopus2-s2.0-85017546223
- TN_proquest1870219718Primo Central grouping is based on the existing FRBR workflow, including the grouping process at the database level (the way the Search engine handles grouping) and the Front End functionality. It is used to prevent duplicate records in the results list.
Unfortunately, many records are not added to FRBR groups because the system considers the metadata are not rich enough. With the increase of records provided by (Open Access) aggregators and repositories, the number of duplicate records will certainly not decrease.
Could Ex Libris improve the FRBR workflow for Primo Central records in order to reduce the number of duplicate
…203 votesHi all,
We are moving this idea to "Closed" to release your votes, as it is no longer relevant with CDI.
Best regards,
Yael.
-
Ensure that CZ & CDI Metadata is Linked Data Ready
I was advised by the Linked Data Group to post this idea here because I submitted the following for the LOD Working Group webinar in December:
Broader strategic and commercial alliances required to ensure that data is ready to be linked?
To engender confidence in CZ and make it linked-data ready, why don’t the Company do business with e.g. Backstage Library Works for authority control clean-up and maintenance?
Metadata is a global commodity so all stakeholders have responsibility for creating, sharing, enriching and maintaining it, and of course there are costs for all of these elements which we could share.
Isn’t this the best way to ease the burden on libraries and leverage our metadata improvements for mutual and sustainable benefit?
I note that this document alludes to the Company taking a lead in creating a new open metadata platform and preserved data in an open format.
https://knowledge.exlibrisgroup.com/Alma/Product_Materials/010Roadmap/Linked_Open_DataPreserving metadata is not the same thing as maintaining it because metadata evolves e.g. authorities are deleted, changed and new ones created.
In light of this I would ask that the Company explore strategic commercial partnerships to ensure that any metadata that they manage (knowledgebases, platforms) is properly maintained.
Jane
I was advised by the Linked Data Group to post this idea here because I submitted the following for the LOD Working Group webinar in December:
Broader strategic and commercial alliances required to ensure that data is ready to be linked?
To engender confidence in CZ and make it linked-data ready, why don’t the Company do business with e.g. Backstage Library Works for authority control clean-up and maintenance?
Metadata is a global commodity so all stakeholders have responsibility for creating, sharing, enriching and maintaining it, and of course there are costs for all of these elements which we could…
16 votes
672 results found
-
Following GDPR Compliances in Digital Wallet App Development
With the rapid growth of digital payments, data privacy and security have become major concerns in eWallet app development. Since digital wallets handle sensitive financial and personal information, complying with regulations like the General Data Protection Regulation (GDPR) is essential for protecting user data and building trust.
GDPR requires businesses to implement strong data protection measures such as user consent management, secure data storage, encryption, data minimization, and the right for users to access or delete their personal data. For companies developing digital wallet apps, ensuring compliance with these regulations can help avoid legal risks while also improving transparency and user confidence.
From your experience, what are the most important steps developers should take to ensure GDPR compliance in eWallet apps? Are there specific tools, frameworks, or best practices that can help simplify compliance while maintaining a smooth user experience?
Looking forward to hearing insights from developers and fintech professionals who have worked on secure digital payment solutions.
With the rapid growth of digital payments, data privacy and security have become major concerns in eWallet app development. Since digital wallets handle sensitive financial and personal information, complying with regulations like the General Data Protection Regulation (GDPR) is essential for protecting user data and building trust.
GDPR requires businesses to implement strong data protection measures such as user consent management, secure data storage, encryption, data minimization, and the right for users to access or delete their personal data. For companies developing digital wallet apps, ensuring compliance with these regulations can help avoid legal risks while also improving transparency and…
1 vote -
Publish the algorithm to create permalinks
Currently the permalinks in Primo contain a secret key which customers can't generate programatically. Using a secret key at all in a URL that is a permalink is questionable.
Permalinks that are dependent on internal secrets and operational details are not in the spirit of nature of long-term commitment.
Permalinks that can't be programatically created based on public available data are also very hard to debug and integrate with external services.
Permalinks should not be dependent on any operational details (for which no long-term commitment can be guaranteed).
Publish the algorithm how this secret key can be calculated or make the key optional (when no key is provided or is empty display a default view)
Currently the permalinks in Primo contain a secret key which customers can't generate programatically. Using a secret key at all in a URL that is a permalink is questionable.
Permalinks that are dependent on internal secrets and operational details are not in the spirit of nature of long-term commitment.
Permalinks that can't be programatically created based on public available data are also very hard to debug and integrate with external services.
Permalinks should not be dependent on any operational details (for which no long-term commitment can be guaranteed).
Publish the algorithm how this secret key can be calculated or make…
17 votes -
Apply the Primo NDE color theme to Primo Research Assistant
In the Primo NDE interface, the selected UI color theme is not applied to the Primo Research Assistant (RA).
Even when a custom theme color is configured for the NDE view (e.g., orange), several RA interface elements still appear in the default blue color, such as:
- the AI stars icon
- the "Start a new topic" button
- navigation arrows in the RA interface.According to Clarivate support, this behavior is expected because the RA interface is controlled by CDI rather than Alma customizations.
Expected behavior: The selected NDE UI color theme should also apply to the Primo Research Assistant interface, so that RA elements follow the same theme as the rest of Primo.
Benefit: This would ensure visual consistency and institutional branding alignment across the entire Primo interface, including the Research Assistant.
In the Primo NDE interface, the selected UI color theme is not applied to the Primo Research Assistant (RA).
Even when a custom theme color is configured for the NDE view (e.g., orange), several RA interface elements still appear in the default blue color, such as:
- the AI stars icon
- the "Start a new topic" button
- navigation arrows in the RA interface.According to Clarivate support, this behavior is expected because the RA interface is controlled by CDI rather than Alma customizations.
Expected behavior: The selected NDE UI color theme should also apply to the Primo Research…
35 votes -
Support MARC field 857 (Web Archive Links) in Primo VE
Please add support for MARC field 857 in Primo VE so that links stored in this field can be displayed in the Links section, similar to MARC field 856.
Field 857 is increasingly used by libraries to store links to archived versions of web resources (e.g., web archive snapshots). Currently, these links are not displayed in Primo VE, even when the field is present in the MARC record.
Supporting field 857 would allow libraries to expose web archive links and preserved web content directly to users and better support web archiving and digital preservation initiatives.
Why this helps many institutions:
Web archiving is becoming more common in libraries and national libraries.
MARC field 857 is intended for archived web resources.
Displaying these links in Primo would improve access to preserved web content.
Please add support for MARC field 857 in Primo VE so that links stored in this field can be displayed in the Links section, similar to MARC field 856.
Field 857 is increasingly used by libraries to store links to archived versions of web resources (e.g., web archive snapshots). Currently, these links are not displayed in Primo VE, even when the field is present in the MARC record.
Supporting field 857 would allow libraries to expose web archive links and preserved web content directly to users and better support web archiving and digital preservation initiatives.
Why this helps many institutions:
…
1 vote -
Dedup and FRBR Test Utility
Could the Dedup and FRBR Test Utility (Configuration/discovery) have the ability to remember the last MMS ID numbers that were looked up? We seem to spend a lot of time going back and forth to the same records trying to get them to match and having to find and paste in the MMS of both, e.g. the print and the eBook records - usually from the Primo URL where I invariably pick up the preceding word, Alma. It would be great if it retained the last couple of MMS searched for to save a bit of time and effort.
1 vote -
NDE UI - Improving UX locations section
The request buttons on item-level are not easily found by our users.
Please note, we have activated item-level requesting for all records, because it seems more logical and straightforward to have all the request buttons in one place. We do not believe returning to title-level requesting is the solution here, but enhancements in the locations section in the NDE UI could improve the experience.The various UX-issues of the locations-section are:
The 'arrow' button is not a clear button
Customers gave us feedback that they find it hard to see you can elapse or collapse cards. They blantly state that they can’t find certain services, not even noticing the arrows. There is no clear affordance that says "open me", nor labels to give it away.The positioning of the buttons is not logical
The hierarchy and sequence of buttons is confusing. Your eye needs to jump from left-to-right all the time, thus it does not have a good visual hierarchy nor a logical focus point flow for your eyes. This results into people missing buttons, or being confused.
The "Call to action"-arrow to open a card appears on two different locations as well, which does not help with discoverability or logical decision-making for the end-user (see point 1).The "elapse-collapse all" icon is not a universal sign
Solving this with CSS has proven not to be a durable solution. CSS updates we have made (screenshots added below) are broken every month when Primo updates parts of the standard CSS. We have looked into the Angular components, but this solution is not stable enough to be trustworthy yet.
Needed solutions are, in our opinion:
Position all buttons to the right
So your eyes do not need to go from left-to-right constantly, keeping focus and giving direction.
The request buttons should also be grouped to the right, but the redesign of the html did not allow for us to do that any longer.Give the arrow a clear label
In this case the call-to-action is viewing the services.Put the availability label next to the location button
So it’s clear whether it is useful to go to the library in the first place.Add a label to the “expand all” button
Just like “filter by”.Optionally: make the links less prominent, to reduce clutter.
We believe that improvement to the section could be useful for all libraries using the NDE UI.
The request buttons on item-level are not easily found by our users.
Please note, we have activated item-level requesting for all records, because it seems more logical and straightforward to have all the request buttons in one place. We do not believe returning to title-level requesting is the solution here, but enhancements in the locations section in the NDE UI could improve the experience.The various UX-issues of the locations-section are:
The 'arrow' button is not a clear button
Customers gave us feedback that they find it hard to see you can elapse or collapse cards. They blantly state that…
-
current-situation-4.png 4 KB -
current-situation-3.png 95 KB -
improvement-with-CSS-customization-3.png 76 KB -
improvement-with-CSS-customization-4.png 76 KB -
current-situation-1.png 48 KB -
improvement-with-CSS-customization-1.png 23 KB -
current-situation-2.png 75 KB -
improvement-with-CSS-customization-2.png 57 KB
10 votes -
Allow an institution (IZ) (Alma/Primo VE) to exclude in retrieval 7XX fields with $5 from another institution within the same Network Zone
In our Network Zone, we work with unique bibliographic records shared by several institutions. The MARC21 7XX subfield $5
is used to indicate local information specific to each IZ.Currently, in Alma and Primo VE searches, 7XX fields containing a $5 from other IZs are included in retrieval and affect
the Dedup and FRBR grouping processes within an IZ. We can only hide these fields from user display by configuring Primo VE rules.
As a result, records retrieved in a Primo VE view of one IZ may include data that are strictly local to another institution and may
even influence FRBR version grouping, producing less relevant or confusing results for users.Requested Enhancement:
We request the addition of a configuration option (at the IZ and/or NZ level) that allows:
Excluding from search indexing and deduplication/FRBR logic any 7XX fields whose $5 does not correspond to the specific IZ, or
At least preventing such fields from being used in retrieval and grouping criteria, while maintaining their local character.Benefit:
This enhancement would respect the cataloging meaning of subfield $5, increase result relevance for each institution, and reduce undesired
effects in the presentation of versions in Primo VE.In our Network Zone, we work with unique bibliographic records shared by several institutions. The MARC21 7XX subfield $5
is used to indicate local information specific to each IZ.Currently, in Alma and Primo VE searches, 7XX fields containing a $5 from other IZs are included in retrieval and affect
the Dedup and FRBR grouping processes within an IZ. We can only hide these fields from user display by configuring Primo VE rules.
As a result, records retrieved in a Primo VE view of one IZ may include data that are strictly local to another institution and may
even influence…15 votes -
Allow patrons to manage email notification preferences by themselves
As a consortium serving more than 200,000 patrons, we request that Primo My Account include a self-service “Notification Preferences” section allowing patrons to select or deselect specific categories of library emails (e.g., courtesy letter, availability letter...), with clear distinction between mandatory and optional notices. This would improve user experience, reduce unnecessary email volume, enhance deliverability of critical communications, and support environmental sustainability by limiting avoidable large-scale email traffic across the consortium.
2 votes -
Ability to configure the Update Password option in My Library Card by user type
We have both internal and external users in Alma. We want to display the option to Update Password to internal users who have their passwords stored in Alma and hide the option for external users who are authenticated via SSO and cannot update passwords via Alma. However at the moment it shows for all users, which is confusing to external users who cannot use this functionality.
17 votes -
Separate display configuration for names in Primo
To configure the order in which a user's first name and last name display in Primo VE (which displays as initials in the top right corner of the screen of NDE) we need to configure the Alma User Details settings. However, in Alma it is easier for us to work with names ordered 'last name, first name' however in Primo we need to order user names 'first name last name' for their initials to show correctly.
Please provide Primo VE with its own configuration settings for the display of a user's name.
5 votes -
Add a field "Author Affiliation"
Could you please add the field "Author Affiliation" for display? Currently, "Author Affiliation" is not displayable in Primo but only in search.
1 vote -
Allow icons display in database search
Allow display of images in database search results view for showing databases icons.
It's the only menu in Primo where it's not possible. Makes no sense !1 vote -
Support turning on/off individual CDI document attributes
Currently, CDI document attributes can only be turned on/off at the view label, and if there is a particular attribute that a library does not want to display, they cannot turn it off as a configuration.
For example, a library may want to turn off the "Primary source" label because it causes confusion when patrons are searching both CDI and local records together.
Please add the ability to enable or disable individual CDI document attributes for display in Primo.
7 votes -
Configuration for cubicle or space reservations
Currently, the resource and space reservation functionality in Primo VE is very limited. It is necessary to enable configurations that make the reservation process faster and simpler. Among the required improvements are:
• Adjusting the available reservation times according to the Library's opening hours, avoiding displaying time slots that are not relevant.
• Allowing the Library team to configure only certain days, instead of automatically enabling all days.
• Unifying the calendar system so that a single calendar is used to select the reservation date, instead of one for the start and another for the end.1 vote -
Additional Format options for resource sharing request form
The resource sharing request form currently only allows selections of "Physical" and "Digital", but patrons might have both preferences and flexibility on the format of their requests. Additional options like "Physical Only, Digital Only, Physical preferred but digital accepted, or Digital preferred but physical accepted" would be helpful for both patrons and ILL staff.
3 votes -
Purchase requests just in top menu (not in Get it section)
We would like to suggest an option to offer the blank Purchase Request form in the Top Menu, while preventing the "Purchase Request" link from appearing in the "Get It" section of the record view.
We want to avoid patrons requesting materials that we already hold or that can be obtained through resource sharing (Rapido).
Currently, there is no configuration to separate these two access points. We tried using GES (General Electronic Services) logic, but it does not work for this specific purpose in Primo VE. The only workaround we found is hiding the link in the record view using CSS, which is not a robust solution.
We suggest adding a native configuration to display the link only in the Main Menu.
We would like to suggest an option to offer the blank Purchase Request form in the Top Menu, while preventing the "Purchase Request" link from appearing in the "Get It" section of the record view.
We want to avoid patrons requesting materials that we already hold or that can be obtained through resource sharing (Rapido).
Currently, there is no configuration to separate these two access points. We tried using GES (General Electronic Services) logic, but it does not work for this specific purpose in Primo VE. The only workaround we found is hiding the link in the record view using…
22 votes -
“Show more items”
Trying to restart this effort-
Add “Show All Items”
Give patrons an option to “Show All Items in a record”. The option “show more items” is not user friendly when searching through long runs
of serials.5 votes -
Support for Email Sending Without Using an Email Client in the NDE UI Email Share Action
Background:
In the previous Primo VE UI, it was possible to send emails using Primo VE’s built‑in email functionality when sharing records via email.
However, in the NDE UI, this functionality has been removed, and the system has been changed so that an email client application must always launch to perform email-based record sharing.
In this situation, shared public PCs in the library—used for search purposes—cannot run email client software, making it impossible to use NDE’s email sending feature.Proposal:
To resolve this issue, we request support for sending emails using Primo VE’s built‑in functionality in the NDE UI as well.
To reduce potential security concerns, we believe it would also be acceptable if this feature were only available when the user is logged in to Primo.Benefits:
Users will be able to use Primo’s email-based record sharing feature even on shared public PCs where email client software cannot be used.Background:
In the previous Primo VE UI, it was possible to send emails using Primo VE’s built‑in email functionality when sharing records via email.
However, in the NDE UI, this functionality has been removed, and the system has been changed so that an email client application must always launch to perform email-based record sharing.
In this situation, shared public PCs in the library—used for search purposes—cannot run email client software, making it impossible to use NDE’s email sending feature.Proposal:
To resolve this issue, we request support for sending emails using Primo VE’s built‑in functionality in the NDE UI as…24 votes -
Enable Pre-filter below the search term input field in NDE UI
Background:
In the previous Primo VE UI, users were able to apply Pre-filters directly below the search term input field. This functionality allowed for more precise and efficient searching without requiring access to Advanced Search.Proposal:
We recommend implementing the same feature in the NDE UI, enabling users to select Pre-filters directly beneath the search term input field.Benefits:
Users frequently use the "contains exact phrase" option or use the “begin with” option. (Especially for non-English speaking users like us.)
Providing Pre-filter functionality in the brief search interface will allow users to execute advanced searches quickly and intuitively, without navigating to Advanced Search.
This enhancement improves usability and aligns with user expectations based on previous UI behavior.Background:
In the previous Primo VE UI, users were able to apply Pre-filters directly below the search term input field. This functionality allowed for more precise and efficient searching without requiring access to Advanced Search.Proposal:
We recommend implementing the same feature in the NDE UI, enabling users to select Pre-filters directly beneath the search term input field.Benefits:
Users frequently use the "contains exact phrase" option or use the “begin with” option. (Especially for non-English speaking users like us.)
Providing Pre-filter functionality in the brief search interface will allow users to execute advanced searches quickly and intuitively, without navigating…9 votes -
Make open access indicator appear for all appropriate resources
Currently, the Primo VE "Open Access Indicator" icon does not appear for resources where the 506 $2 vocabulary value is not equal to "star". This creates a situation in which the open access indicator is not reliable to users as a way to identify freely-available resources.
According to approved cataloging practice, there are a variety of valid vocabularies that open access 506 values can be taken from. In addition, the STAR (Standardized terminology for access restriction) vocabulary is no longer actively maintained, and its appearance in catalog records will likely diminish over time.
The Access Restriction Term Source Code List (https://www.loc.gov/standards/sourcelist/access-restriction.html) provides multiple source codes that can be used for the 506 field:
cc (Creative Commons)
coarar (COAR Access Rights Vocabulary)
rs (Rights Statements)
star (Standardized terminology for access restriction)
wikidata (Wikidata)Primo's open access indicator should also recognize these vocabulary codes as valid sources of information on access restrictions, and assign the open access indicator as appropriate to resources with the relevant codes from those vocabularies.
Support has advised us that there is no way to locally configure the open access indicator to appear for resources with other vocabularies noted in the MARC 506 field. They have stated that an enhancement will be necessary to change the current logic behind which records get the open access indicator.
Currently, the Primo VE "Open Access Indicator" icon does not appear for resources where the 506 $2 vocabulary value is not equal to "star". This creates a situation in which the open access indicator is not reliable to users as a way to identify freely-available resources.
According to approved cataloging practice, there are a variety of valid vocabularies that open access 506 values can be taken from. In addition, the STAR (Standardized terminology for access restriction) vocabulary is no longer actively maintained, and its appearance in catalog records will likely diminish over time.
The Access Restriction Term Source Code List…
224 votes
- Don't see your idea?