Problem Description
When users are logged into their account in Primo VE, the title Applications of Plasma-Sprayed Ceramic Coatings displays as being Available Online (delivery.code.not_restricted).
However, it is not available online. In the View It section, there are services for related records, but no links to that article.
The DOI for the article directs to scientific.net, which our institution doesn't have a subscription to. We don't know why Primo VE indicates that we do.
This is frustrating for users who anticipate access to a resource only to find that there is no access at all.
Title: Applications of Plasma-Sprayed Ceramic Coatings
MMSID: None. CDI record.
Permalink: https://search.library.ucr.edu/permalink/01CDL_RIV_INST/1ikr3qb/cdi_openaire_primary_doi_0655c0bc838973bffa763952b615f775
Case Comments
Emphasis by Jessica Kruppa, because Martin and I got a bit off track with another issue.
User | Date | Comment |
|---|---|---|
1/26/2024 8:49 AM | Hi Jessica, Thank you for contacting ExLibris support, I am investigating this record and I’ll get back you soon with my updates.. Regards, | |
2/1/2024 12:19 PM | Hello Jessica, Thank you so much for your patience! I have discussed this case with my team and I have also performed some tests in a copy of your environment and found that removing the related titles section removes the “Available online” label. As this needs more deeper investigation, I am sending the case to my colleagues from Primo Tier 2, they will be updating you soon. Feel free to ask any questions in the meantime. Regards | |
2/6/2024 2:27 PM | Hi Jessica, I have assumed responsibility for your case and have reviewed the information you submitted. I will be investigating this issue, and will update you as significant progress is made. Please let me know if you have any questions in the meantime. Kind Regards, | |
2/27/2024 11:47 AM | Hi Jessica, I appreciate your patience. I am still looking into the case, and will update you once I have more information. Kind Regards, | |
3/5/2024 1:16 AM | Dear Jessica, This is Martin from Primo Tier2 Support team and I have assumed responsibility for your case. I have briefly investigated and found out the current behaviour is by design, due to your related records configuration. This is described in all the details at and Whether a specific record has related viewit services can be seen via DISPLAY CTO button through &displayCTO=true param, e.g. You can identify the related services by is_related_service = true Currently we do not distinguish the availability label between related titles and original titles in the availability statement, so it appears as Available Online for either of them. It basically means that there are fulltext services. In your example above, they all apply to related records only. Please let me know if you have any additional questions or comments. Thank you and best regards, Martin | |
3/6/2024 9:54 AM | To clarify, you are telling me that when a search result claims "Available Online" for a specific resource it could mean either: a) The provided link leads directly to the accessible online version of the described resource or b) The link directs to a list of potentially related resources (journals, conferences, etc.), as the described resource itself may not be available online. If I am correct in the above clarification: This is poor user design and this ticket needs to be escalated to the product/project manager. Imagine searching for "Carrots" on a store's website. You see a card saying "1 pound of Carrots" and "Available Now!" But when you click the link, instead of finding a link to buy 1 pound of Carrots, you get options for 2 pounds of Parsnips, 1 pound of Potatoes, or a single Turnip. Even though these items are related, it's not what you were looking for, or what the result card promised. This kind of misleading info can make searching frustrating and give you a bad experience. An item's availability statement should not be affected by the availability of a similar or related item. Users expect accurate and relevant information when conducting searches, and encountering misleading information like this contributes to a negative overall user experience. | |
3/6/2024 10:05 AM | Hi Jessica, Thank you for your update and yes, your clarification has been correct. I will pass your feedback and reasoning on our Product Management and will keep you updated afterwards. If I understand correctly:
Please can you confirm? Thank you and best regards, Martin | |
3/6/2024 11:11 AM | Ideally, the availability of a related title should not affect the availability statement in the brief results. But yes, you are correct. delivery.code.not_restricted - the record has full text availability This needs to extend to the the various available online codes found in the PrimoVE Calculated Availability Text code table. This is the list of codes with "Available Online" as their default descriptions in the code table. No one appears to be certain which ones apply to Primo VE and not BO, per ticket 07006689. | |
3/7/2024 2:30 AM | Hi Jessica, Thank you for your update and confirmation. Please let me explain further - yes, there is a bit more of complexity here, as the availability for CDI records is as follows:
Now, in Full Display, you may also receive getit services (as part of RTA mechanism), if there is any relevant Alma-P inventory. As you have enabled also Getit related services, you may see physical availability for related titles, too. Should I expand my consultancy with our Product Manager also to Physical availability, or should I keep it strictly limited to Online availability. As the same principle applies also to physical availability - you can see only from Getit tile that the availability belongs to related titles, but not from the availability statement Available at ... Thank you and best regards, Martin | |
3/7/2024 9:22 AM | I think we should definitely expand this to Physical availability. The end goal is to ensure that users are getting accurate, clear, and understandable availability statements, and that means being able to identify which labels appear, when, and being able to change the statement text. And thank you for explaining what codes the CDI availability labels are based on, and the order of operations! I have been trying to identify which delivery.code (ticket 07006689) does what in the Calculated Availability Text table, and it's been really slow going trying to figure it out on my own. That helped me at least identify 5 that I hadn't figured out yet. You don't happen to have documentation hiding over there somewhere that would help me fill out the rest of the table, do you? | |
3/7/2024 9:41 AM | Hi Jessica, Thank you for your update. Happy to hear the provided information has been useful to you. Regarding the other labels: delivery.code.ext_not_restricted are both coming from Primo VE external records, harvested by Discovery Import Profile, please see more about them at As for this label: delivery.code.esploro_status.not_restricted I am not familiar with this one, but the label itself suggests it is related to Esploro (which is another product on our High-Ed platform). If you are not using this solution from us, I believe you can safely ignore this label. For other availability labels mentioned in SF case 07006689, this indeed needs to be checked by our development in more details. Now I am going to consult with our Product Manager about the dedicated labels for both Related records from Getit and Viewit, and I will keep you updated afterwards. It might be handled as an enhancement. Thank you and best regards, Martin | |
3/20/2024 7:40 AM | Hi Jessica, This is to update you that I am still checking about the issue (dedicated labels for related services in the availability statement) with our Product Manager. I will keep you posted, once I have any more information available for you. Thank you and best regards, Martin | |
10/13/2024 5:23 AM | Dear Jessica, Our Product and Development team has reviewed this issue, and I want to update you. After a thorough examination, it has been decided that a solution for this is currently not in the Primo work plan. Once this will be fully addressed, we will publish the improvement via Primo VE Release Notes in: We are closing the case by setting the status to “Awaiting Customer Confirmation”, and the case will automatically close after the standard waiting period. Best Regards, | |
10/14/2024 9:27 AM | Dear Ishay, Thank you for your update. I appreciate the time you and your colleagues have taken to investigate this issue. However, I must express my concern with the decision not to prioritize a resolution at this time. While the Related Records feature provides value in the Full Record Display, its unintended consequence of misleading users on the Brief Results page cannot be dismissed as "working as intended." From a product management perspective, this is a usability issue that directly impacts the user experience by presenting inaccurate availability labels. Users expect accurate information in search results, and current behavior introduces unnecessary frustration and mistrust. We now face two difficult choices:
This puts institutions like ours in the difficult position of either sacrificing functionality or sacrificing usability—both of which are unacceptable outcomes for any system. It is disappointing that the product team released this feature without fully addressing its impact on usability. This oversight shifts the burden of managing user frustration with your software onto the libraries, which is both unfair and unsustainable. Additionally, I am concerned that this design issue reflects deeper, systemic problems in your software development process. With the NDE in development, we fear that these same issues-- poor usability design, limited user testing, and lack of attention to edge cases-- will carry over into the new platform or worsen. I understand that development timelines may be constrained, but I respectfully request that you re-evaluate this issue. Accurate search results are a critical part of the user experience, and we hope the product team will prioritize it accordingly in future development cycles. Once again, thank you for your attention to this matter. | |
10/15/2024 12:12 AM | Hi Jessica, This is Martin, back on the case. Thank you for your update and for detailed reasoning. Please let me explain our stand - although we are closing the case, we do not dismiss this idea. Instead, our Product Management will keep it in their plans for Primo Roadmap and will include it, once possible. Also I have attached your feedback to our Product Manager, so they are aware of the current design issue and potential implications on NDE. Once this will be fully addressed, we will publish the improvement via Primo VE Release Notes in: We are closing the case by setting the status to “Awaiting Customer Confirmation”, and the case will automatically close after the standard waiting period. Thank you and best regards, Martin |