Related product I-Share

Alma/Primo VE Known Issues

Updated: 8/27/2021

General Alma Troubleshooting and Problem Reporting

expand / collapse all

Problem: When a user logs into My Library Card through Primo VE, not all the user's loans or requests from all I-Share libraries are listed on one page. The user must click through each institution name to see the loans and requests from that specific library. Many users would like to see all their loans or requests--no matter which institution they are from--listed on one page.

Currently, there is no way to customize the My Library Card to change this behavior; the default is the only option for displaying loans and requests. There is an Ex Libris Idea Exchange topic that requests better design of the My Library Card page, specifically so users can see all their loans/requests from all institutions one one page. Vote and comment on this Idea Exchange topic at:

This is a known issue that is the result of a temporary workaround to fix another issue.

Background on this issue:
Some users’ I-Share requests are being automatically rejected because Alma is unable to automatically create a linked user record for the patron in the item’s IZ.
Ex Libris support has found the source of the bug and have planned to include the fix in the November 2021 update release (date tentative).

Ex Libris support has told us that until the bug fix is in place from that future release, CARLI staff will need to implement a temporary work-around in Alma configuration so that users affected by this bug can place I-Share requests.
What this means for your library while the work-around is in place, when searching for users from another I-Share library using Fulfillment> Checkout/Checkin> Manage Patron Services> with “Find user in other institution” checkbox checked:

  • You will only be able to search for users from another I-Share library by an identifier, such as Primary ID, Barcode, or IID.
  • You will NOT be able to search for users from another I-Share library by name or by email address.

The work-around began on Monday, July 26th at noon central when CARLI Office staff made the edit in Alma Configuration for all I-Share libraries.

CARLI Office staff filed SalesForce case #00972157 for the request issue; a fix is anticipated in the November release.


Staff can search for the I-Share user by an identifier, such as Primary ID, Barcode, or IID.
Contact the item's home library, or the user's home library as needed for this information.

The report from the Fulfillment Job "Loans - Overdue and Lost Item" does not accurately report the number of "Loans Which Notification Was Sent For - by Profile" for Lost profiles.

The notifications do generate/send, but the job report does not include the numbers; even when users are sent a notification letter for a lost profile, the report always lists the "Number succeeded" and the "Number failed" as zero for the lost profiles.

CARLI Office staff filed SalesForce case #00976173; it is under investigation by Ex Libris.


Staff can review the area of the report for "Change to Lost - by Profile" and review the list of succeeded or failed status changes. From those lists, staff can review the associated user's Attachments tab to double-check that the letter was sent to the user.

On Alma screens where the staff user is prompted to scan a barcode, Alma is anticipating the selection of a single unique item that has an explicitly matched barcode value; that is, the barcode scanned into Alma must match the complete contents of the item record barcode field. The item record barcode field is a text field with no apparent limitation on size or content, and the field allows blank spaces to be entered anywhere. If the barcode value is preceded or followed by one or more blank spaces, these spaces will prevent a scan from matching on the correct value.

Alma search screens will still match on barcode. We believe this is because Alma search screens include implicit keyword truncation.

CARLI Office staff filed SalesForce case #00876813 on 9/4/2020, which currently has a status "pending development."


In order to locate the specific item that you need for a transaction, click on the select from a list button, which will open a search window scoped to physical items. Search for the item by barcode or other known value, then select the correct item from the results. Alma will paste the actual value from the barcode field into the scan box.

  • This workaround will not work for item records that have no value in the barcode field.


Staff should search for the item separately and correct the item in the physical item editor.

  1. Search for Physical Items, using barcode or other known value.
  2. Locate the item in the results and click Edit Item.
  3. Locate the barcode field and highlight the full contents of the field. This should show where blank spaces are present.
    An image of an Alma item record in the physical item editor. The General tab (black text on white background) is active; inactive tabs for ENUM/CHRON and Notes (blue text on gray background) are visible. Under General information, the first field is Barcode. A barcode value of "38198313193508 " is highlighted (white text on blue background), which reveals the blank space trailing the numbers.
  4. Delete the blank spaces from the field. Verify that the rest of the barcode value is correct and matches what is on the physical piece.
  5. Click Save.

CARLI staff have a shared analytics report, Item Maintenance Barcode Has Trailing Space Character, to help identify records with this issue.

This issue affects libraries that use Microsoft Azure for their SSO (it affects both OpenAthens users and non-users). Microsoft Azure rejects SAML Request URLs that contain XML tags. Unfortunately, some OpenURLs get constructed which include XML tags [1].

Here's what the Azure error messages look like:

Sorry, but we're having trouble signing you in. AADSTS75005: The request is not a valid 
SAML 2.0 protocol message.

Example solution that Cindy from TRN came up with [3].

NOTE #1: Some SAML providers, e.g., Shibboleth (at UofI), do not seem to be affected as they will process URLs with the XML tags without complaint.

NOTE #2: This issue only occurs for patrons who have not yet logged into their campus SSO before accessing the OpenURL in PrimoVE. The problem surfaces when PrimoVE redirects the patron to campus SSO for authentication, a process which involves passing the OpenURL (containing XML tags) in the "RelayState" parameter [2] (this is how PrimoVE determines which page to take the patron upon successfully logging into campus SSO).

If a patron is already logged in, PrimoVE doesn't need to redirect the patron to campus SSO for authentication. This means it doesn't involve passing the OpenURL (containing XML tags). Hence there's no issue.

[1] An example of an EBSCO OpenURL containing XML tags (in the "pid" parameter):
*20Fran c27ois&issue=4&isbn=&spage=541&pid=*3Cauthors*3EDermange,*20Franc27ois*3C*2Fauthors*3E* 
20Rel igion*20Database*20with*20AtlaSerials*3C*2Fdb*3E&title=Revue*20de*20l*27histoire*20des*
*20dette&sid=EB SCO:Atla*20Religion*20Database*20with*20AtlaSerials&volume=237&issn=00351423&genre=article&doi=
 contains XML tags in the "pid" parameter: &pid=%3Cauthors%3EDermange,
%20Franc27ois%3C%2Fauthors%3E% 3Cui%3EATLAi5IE210125000804%3C%2Fui%3E%3Cdate%3E20200101%3C%2Fdate%3E%3Cdb
...which when decoded looks like this: &pid=Dermange, FrancoisATLAi5IE21012500080420200101Atla Religion Database with AtlaSerials

[2] Example SAML authentication request with a "RelayState" parameter that is set to an OpenURL containing XML tags (in the "pid" parameter): SAMLRequest=lZLLbtswEEV%2FReCeEvWyLcJyoEg2asAJgrwW3THU2CZAkSqHcpO%2FjyLDqLspmvU87r1nZnn z3ungBA6VNSWJQ0YCMNK2yhxK8vK8oQtys1qi6HTPq8EfzSP8GgB9MM4Z5FOhJIMz3ApUyI3oALmX%2FKm62%2F EkZLx31ltpNQkqRHB%2BFKqtwaED9wTupCS8PO5KcvS%2BRx5FiuJROKDembB3qrMhvGv15hQenB36UNou6swh6 lv8IUyrYWcPypCgGU0pI%2FyU47JMf9XCTkln0e69NVoZmFbMWjmf72VG2fytpZkQQBeQtDQtEgZ5nsJito%2B% 2B0iUk2FgnYQpfkr3QCCTYNiWpijyrZ2u2iau0aNa3VV3kxTpt6ux2XVRZuhB9y9KxFx8EojrBn2nEAbYGvTC%2 BJAlLYsoymrDnOOfxnMdxOGPFTxK8Xu4yciTnK%2FBp1l3h%2Fzd9cWFOVt8lPMFbRleqZwtJz%2B9HnW3zYLWS H1dWkv9%2FBa3t79qB8CMV7wYg0eos9febrT4B&RelayState=https%3A%2F%2Fi-share- id%3D01CARLI_TRN%3ACARLI_TRN%26date%3D20200101%26aulast%3DDermange%25252C%25252A20Franc 27ois%26issue%3D4%26isbn%3D%26spage%3D541%26pid%3D*3Cauthors*3EDermange%2C*20Franc27ois *3C*2Fauthors*3E*3Cui*3EATLAi5IE210125000804*3C*2Fui*3E*3Cdate*3E20200101*3C*2Fdate*3E* 3Cdb*3EAtla*20Religion*20Database*20with*20AtlaSerials*3C*2Fdb*3E%26title%3DRevue%25252 A20de%25252A20l%25252A27histoire%25252A20des%25252A20religions%26atitle%3DCalvin%25252C %25252A20la%25252A20gr%25252A%25252AAce%25252A20et%25252A20l%25252A27%25252A%25252AAthi que%25252A20de%25252A20la%25252A20dette%26sid%3DEBSCO%25253AAtla%25252A20Religion%25252 A20Database%25252A20with%25252A20AtlaSerials%26volume%3D237%26issn%3D00351423%26genre%3 Darticle%26doi%3D%40%4001CARLI_TRN%40%40primaw


[3] For EBSCOhost source citations:

 EBSCOadmin solution that Cindy Bowen from TRN came up with [3]. Log into your EBSCO Admin account. Go to "Linking" and then "Custom Links" section. Click on "Modify".


Then click on "SetUp/Maintain Custom Links" and then open your link resolver profile. This library called that "Alma":


For whatever reason, there was &pid= followed by elements in < > added to the end of the Query String. That added a string like this (decoded for readability) to the OpenURL, which apparently our authentication system took offense at.

pid=Dermange, Franc27oisATLAi5IE21012500080420200101Atla Religion Database with AtlaSerials

The EBSCO-derived URLs were longer and messier than the URLs produced by other sources.  Removing that &pid= section from the URL makes the linking work. 



The working Query String looks like this:


Cataloging levels on bibliographic records protect the integrity of metadata, requiring that only catalogers with sufficient expertise and responsibility may modify the records. However, the cataloging level of a record should not prevent other libraries or catalogers from using the shared bibliographic data. According to Ex Libris' documentation on cataloging privileges, if the cataloging level of a record is higher than the cataloging privileges for the user, the user may still add inventory, add local extensions, and modify record suppression.

Currently, the new metadata editor blocks most of these functions when the record's cataloging level is higher than the user's cataloging privileges.

  • The Save menu is unavailable.
  • The Editing actions menu is unavailable, which prevents adding local extensions.
  • The Record actions menu is limited to only releasing records.
  • The Inventory menu grays out the option for adding new MARC21 holdings; the Add Item option appears to not function.


Catalogers who need to add local extensions to bib records or who need to add holdings and/or orders to bib records with high cataloging levels should revert to using the old metadata editor. In the new MDE, click the "Old MDE" button in the top right corner of the MDE workspace.

If a record has cataloging level of 90, report that record to CARLI staff. Records should only have level 90 for CARLI network zone maintenance projects. No catalogers at I-Share libraries should have a cataloging privilege of 90.

CARLI filed Ex Libris support Case 00943926; Ex Libris reported a fix is scheduled for the June 2021 release.

When library staff run any job that affects Purchase Order Lines (POLs), including:

  • Update PO Lines Workflow,
  • Update PO Lines transactions,
  • Update PO Lines Information – Advanced,
  • Update PO Lines Information,
  • Change PO Lines Status

if the set that is used for the job was created prior to 3/7/2021, the job will add ALL POLs from your Alma Acquisitions to the set, rather than only the POLs actually defined in the set you created.

Be sure to pay attention to the number of POLs that will be updated by the job, as stated in the warning given by the job before you submit it. If the job indicates that it will updated a much higher than anticipated number of line items, it is a sign that your job may be affected by this issue. 


Prior to running any of the jobs listed above, create a new set containing the POLs (do not reuse any set you had previously created before 3/7/2021).

Ex Libris hopes to have a fix in place for the problem by May 2021.

CARLI recommends deleting your old sets of POLs to ensure you are not accidentily running these jobs on the incorrect purchase order lines.

Primo VE may display the I-Share request link inappropriately in the Get It section even when there are no other holdings at any other I-Share institution and no "Get It at Other Institutions" section.  Ex Libris has told us that the system is not able to discern that there are no other consortial holdings. CARLI staff are investigating other methods to hide the I-Share request link in these instances.

When Alma is checking whether to send an institution a patron's requests as part of a ROTA, Alma checks the item's availability and requestability.

The problem is that Alma does not double-check that the same item that was requestable is also the same item that was available (they are distinct searches).

When an institution only has one copy of a title, the availability and requestability of the item are in sync for that same item. However, if an institution has multiple copies, where some are requestable but unavailable (such as charged, missing, requested, etc), and some are available but not requestable (such as reserves, reference, special collections), Alma will permit the request to be placed. This request then "queues" to wait for the requestable item to become available.

CARLI filed Ex Libris support Case 00926351, and will be in touch with libraries in March about arranging the fix suggested by Ex Libris support.

We've had a report from one of our I-Share libraries that:

  • when their institution has multiple copies of a title,
  • and that title has holdings in different locations that are in different fulfillment units, where one fulfillment unit IS requestable and the other fulfillment unit IS NOT requestable,
  • then Primo VE does not offer the local request link for local patrons, even though one copy should be requestable.

CARLI filed Ex Librus support Case 00934900.

When the item is checked out to the requesting patron at a location that is not the location recorded in the patron's request, the "completion" of the request is not communicated back to the patron's home library. As such, the request lingers in both the patron's account and in the patron's home library's Borrowing Requests list. The item's library does consider the transaction complete, however.


  • Sometimes, a patron may place a request for an item, and then for reasons decide to pick it up at an I-Share library that is not the library they had noted in their request.
    This could be due to scenarios such as:
    • The pick-up library being closed to the public so that pick-up library wants to route the item to another open library for the patron.
    • The patron contacts the item's library after it was processed to say "wait- let me pick it up there after all".
    • There was some problem with the request/transaction, so the patron's library asks the item's library to complete the charge.
  • We realize that the ideal situation would be for staff to Edit the request to modify the pick-up institution/location while the request is still in the pick from shelf list. But, sometimes that is not possible and the request has already been processed through "scan in items" to put it in transit.

Work Around:

  • If library staff or a patron becomes aware of a request where this has happened, either party can cancel the request after the item is checked out to the patron's account.
    • The patron can cancel the request through Primo VE.
    • Library staff can cancel the request through:
      • The user's fulfillment activities> request tab
      • If an I-Share request: Fulfillment> Resource Sharing> Borrowing Requests
      • If a local request: Fulfillment> Resource Requests> Monitor Requests & Item Processes
    • Note- canceling the request will affect request statistics, but, it is currently the best work-around.

 CARLI has filed Ex Libris support Case 00917034

We've been hearing from library staff that patrons are reporting that they are not receiving some Alma Letters, specifically, the "On Hold Shelf Letter" aka the "FulPlaceOnHoldShelfLetter" letter, and typically when the letter is being sent by another AFN member institution, but, also sometimes when the letter is generated by the user's home institution.


  • The "On Hold Shelf" letter in Alma is generated by the Item's owning library, rather than the patron's pickup location.
  • We can see on the Attachment tab in the linked user record at the Item's owning library, that Alma appears to be generating the letter.
  • The behavior is not consistent; some users from an institution report receiving the letter consistently with no issues, while other users report not receiving the letter.
  • Some users do find the letter in their spam filter and junk email folder.

 CARLI has filed Ex Libris support Case 00925814

In Alma, if staff check out both I-Share AND local material to the same user in the same session, and staff check out the AFN material first, the local materials will not display under "loans of this session."

This is a display issue only; the local material is checked out to the user's account despite not displaying under the "loans of this session."

To confirm the charge:

After completing the charge transactions, look the user record up a second time and look at the users's charged material. The local material should be listed on the Loans tab under the "All Loans" option. The I-Share/AFN material will be listed on the Network Activity tab.

CARLI has filed Ex Libris support Case 00934438

The Primo VE Local Request form is showing the institution and library even if the hold shelf is not enabled for the circulation desk.


From what we understand thus far, turning off all circulation desk hold shelves should fully remove an institution from the list of pick-up institutions/locations visible to the user in Primo VE.

  • We're finding that the behavior is different in the Resource Sharing Request form vs. the Local Request form.
    • The Resource Sharing Request form is behaving as we'd anticipate and not showing the institution or library if the circulation desk does not have a hold shelf.
    • The Local Request form is instead showing the institution and library even if the hold shelf is not enabled for the circulation desk.

CARLI has filed Ex Libris support Case 00935915

In Alma, if an institution adds an identifier to the Configuration> User Management> Collaborative Networks> Searchable Identifiers table, then, their patrons can no longer be searched at other I-Share/AFN member institutions by name or by email, even if the user's name/email is unique. Occasionally, library staff have limited the searchable identifiers in a way that prevents searching by barcode or IID as well.

What to do: If you find another I-Share institution's users are not searchable by name or email (when unique), by barcode, or by IID, please email and we can review the configuration and reach out to the institution. 

CARLI has filed Ex Libris support Case 00926943 about name/email identifiers.

The Alma User Purge job is not AFN-aware; it will allow the deletion of a user record from the user's home institution's IZ even when the user has active transactions at another AFN institution.

These "orphaned" linked user records are confusing for both users and library staff. Examples of the confusion we've encountered thus far:

  • If the user's home institution performs a purge and then re-loads records, the orphaned linked user records in the other AFN member institutions do not re-connect to the new version of the user's home record. The user is then confused why they cannot see their AFN-charged material on their account.
  • If the item's home institution contacts the user, the user will often contact their home institution for assistance. The user's home institution cannot see the user's record in their own IZ anymore so they are confused.
  • If the item's home institution is unable to contact the user, they often contact the user's home institution for assistance. The user's home institution cannot see the user's record in their own IZ anymore so they are confused.

CARLI has filed Ex Libris support Case 00933368

In Alma, when looking at your institution's Fulfillment> Resource Sharing> Borrowing Requests list, requests that are stuck in "Ready to be sent" status are likely ARTICLE requests, which we don't share through Alma.
See also Known Issue below, "I-Share request link sometimes displaying on Articles (posted 12/3/2020)"

  • How to tell if it's an article request:
    • If they "Ready to be sent" and the partner institution is KCC. We are uncertain why many of these article requests lately are pointed at KCC, but it is nothing that KCC is either doing or not doing. CARLI Staff are working with Ex Libris to identify why this is the case.
    • If there are volume, issue, page numbers, or DOI showing in the request in Fulfillment> Resource Sharing> Borrowing Requests.
    • If you click to view/edit the request, and the "source" line includes wording such as JSTOR, ProQuest, or other database names.
  • How are these requests getting into Alma?
    • Here are the reasons thus far that we've found for when article records include I-Share request links in Primo VE:
      • When an article is found outside your institution that your institution has physical holdings for, the I-Share request link is displayed. We are working on creating a case to stop this from happening.
      • If the user has used the "Expand/Filter/Tweak My Results" option and the search scope is expanded out to the CDI.

CARLI has filed Ex Libris support Case 00931116

Current workaround

  • What do do with these requests if you are the patron's library:
    • If you can determine that it is an article request, it cannot be filled through Alma. As such, you can:
      • Transfer the information out into your regular article-request system on behalf of the patron.
      • Cancel the patron's request and include a note in the cancellation asking them to re-request through your usual article-request system.

We've heard from a few I-Share libraries that they have items currently on their Alma expired hold shelf's "Send to Institution" tab, that are unable to be transited back to the item's home institution, even when staff are following the correct "Best Practices: Alma Hold Shelf Maintenance" steps from the How To: Staff workflows for Alma Requests- Local and AFN page.

  • When they select the item's checkbox and use the transit button at the top of the screen, they receive a pop-up message that says "Item was put in transit," however, the item remains on the expired hold list and the status is not updated to transit.
  • If they use the transit link for the individual item, there is no pop-up, but the item still remains on the expired hold list and the status is not updated to transit.

CARLI has filed Case 00898744, which is pending development.

Current Workarounds:

  • For items "trapped" on the hold shelf as described above, library staff can go to Fulfillment> Resource Requests> Scan in Items> Scan the barcode of the I-Share item trapped on hold.
    • Processing the item through Scan in items:
      • Should remove the item from the Expired Hold Shelf> Send to Institution tab.
      • May produce a "Resource Request Slip" letter (the pick from shelf letter) instead of the regular "Fulfillment Transit" letter; this is okay, since this is a work-around.

Each institution has a daily scheduled job, Publish bibliographic record (DataSync) to OCLC, which sends copies of added, updated, and deleted records to OCLC via secure FTP. Deleted records are sent with the Leader/05 value of "d". OCLC reports that records must include both the correct leader value and a 994 $b containing the OCLC library symbol. I-Share libraries have reported that deletions are not being processed on OCLC's end.

Current Workarounds:

  • Manually delete holdings from OCLC via Connexion or Record Manager when deleting records from Alma.
  • Generate lists of deleted OCLC numbers with their OCLC numbers from Analytics or the Alma Deleted Repository, then process those lists through Connexion client's batch processing or Record Manager's delete holdings function.
  • Change the publication status of the record prior to deletion (Tools > Set Management Tags > Publish to OCLC > Don't Publish). A library would have to wait at least a day before deleting records modified in this way.

Each institution has a weekly scheduled job to publish electronic holdings data to WorldCat. Administrators reviewing job history (or receiving System Job Messages) will notice that the Publishing Platform Job Publish electronic holdings to OCLC job will have "Completed with Errors." Reviewing the job's Events report (actions menu > Events) shows an event description of "FTP Connection Fail." This is not affecting all institutions, and all are using the same OCLC ftp server. CARLI has filed Case 00896694.

Some I-Share libraries are currently closed to the public for in-person access (Library A), but are willing to allow another I-Share library's patrons (Library B) to request their materials for pick-up at another I-Share library (Library B or Library C).

  • If Library A is allowing local requesting of their own materials for their own Library A patrons, it is not possible to prevent Library A from showing in PrimoVE as a pick-up location for other I-Share libraries' patrons.
    • If Library A is NOT allowing local requesting of their own materials for their own Library A patrons, turning off all circ desk hold shelves will fully remove an institution from the list of pick-up locations visible in Primo VE.
  • Ex Libris Support has confirmed there is currently no way to turn prevent Library A from being allowed as a pick-up location.

Please vote and comment on this Idea Exchange for this topic; development is pending!

After running the "Change Bulk Due Date" job for all I-Share libraries (for all I-Share patrons, and for local patrons at the discretion of the library) as part of the Proposal on Alma Bulk Due Date Extension Approved by CARLI Board of Directors, the CARLI Office has received a few reports from library staff that some eligible transactions may not have had their due dates updated.

CARLI Staff have sent an email to the Alma-L email list to see if others have experienced this issue, and are compiling notes to submit to Ex Libris for investigation.

Current workarounds:

  • Contact with information about the patron and the items that were not renewed. We can evaluate whether renewal was anticipated based on the Bulk Due Date change jobs that we ran as part of the project, and rerun the jobs as needed.

Possible cause, #1:
Alma does not support opening multiple copies of the User Details screen. When the User Details screen is open in one browser tab or window, and another tab contains either the User Details tab or the Register New User screen, clicking save on the edited or newly created user will also save changes over the user in the other tab. CARLI staff have observed this activity in cases where a library staff member opened their own user details screen for reference while also creating or editing a new user in another tab.

CARLI has opened Ex Libris Case 00893658.

Current workarounds:

  • Library staff should create a screen capture or a reference sheet of user details that are needed.
  • If staff need to have multiple screens of the same type open, use different browsers for additional instances, or use a browser's privacy or "in cognito" modes to keep the sessions separate.

Possible cause, #2:
When a library does a SIS synchronization, Alma is matching only on the user's primary ID; it is not taking into consideration if the user is a "linked user" record or not. As such, an I-Share user's linked user record saved to another IZ may be overwritten with a local patron's information if their primary ID is a match. The scope of this issue is minimal, as it only affects linked user records that were migrated from Voyager with an unprefixed Primary ID, where the format matches the primary ID used by the home institution performing the SIS updates for their local patrons.


  • When Alma imports a new linked user record for an I-Share patron, the linked user record imported in Alma is assigned a random 15 digit number, where the last 4 digits are the item's home IZ's Ex Libris code. This 15 digit number that ends with the Ex Libris code is unlikely to have a match.
  • The issue is that I-Share patron stub records that were migrated from Voyager, sometimes migrated with their Primary ID set as their IID from their home institution, which may have been an unprefixed number. As I-Share libraries began running SIS synchronizations, sometimes that un-prefixed primary ID in the linked user record could match to a local patron's Primary ID.

CARLI has opened Ex Libris Case 00936354.

Alma Link Resolver screens in Primo VE are slow to respond. When searching in external electronic resources, a user will click an openURL link to find the item availability in Alma. The response time of the link resolver page takes 10+ seconds to load and the View It section with links to content may take additional time to load.

  • Current Activity:
    • CARLI has opened a case with Ex Libris (Case 00856824) to address slow response time in the link resolver.
    • Ex Libris released updates to Alma and Primo VE with the August 9 system update that improved response time for electronic resource and holdings display data.
    • Ex Libris released additional updates in the September 13 system update to address link resolver responsiveness.
    • Ex Libris plans additional updates for the November monthly release.
    • I-Share Library staff may contribute additional reports on response time issues via the I-Share Response Time Reporting form.

CARLI has activated a number of consortial full-text electronic resources in our Network Zone because they are purchased by CARLI for all of our I-Share member libraries. These resources correctly display in search results of Library Catalog searches (IZ) and search results of All I-Share Libraries searches (NZ+IZ). However, if the "Available online" facet is used on search results that include NZ-activated resources, they are being removed from the results list in Primo VE. CARLI has opened Case 00878507.  In Jan. 2021, Ex Libris declared this to be a Defect; current status is "Pending Development".

Primo VE's My Library Card display lists items checked out or requested from different I-Share institutions separately under a tab for each institution on the left-hand side. There is currently no way to collapse these or to see a unified list of all items a user has; this is a significant change from what users were accustomed to on VuFind's My Account page. 

  • If you would like to let Ex Libris know that this functionality is not ideal for consortia, please vote for and comment on this Idea Exchange idea.
  • As a stopgap measure, please also consider voting for and commenting on this Idea Exchange enhancement requesting that the "Has Activity" toggle on the Institutions list be set as the default.

Primo VE will allow a patron to place an I-Share request for a title, even if no I-Share library can fulfill that request; Alma then updates the request to "Canceled" and notifies the requesting patron via email. (originally posted on Fulfillment pages 7/15/2020)

On the I-Share Request Form in Primo VE, the "Preferred Local Pickup Location" and "Preferred Pickup Institution" of the user's home library are displayed. If the user chooses a different Institution from the list, then the "Preferred Pickup Location" appears beneath the Institution for the user to choose the location at that other Institution. (originally posted 8/24/2020 on Fulfillment pages)

  • If the user chooses a different Institution, the "Preferred Local Pickup Location" field does continue to display above the Institution, but, the "Preferred Pickup Institution" field controls where the item will be sent.
  • At this time, we do not have a way to make the "Preferred Local Pickup Location" disappear if the user chooses a different Institution that is not the user's home Institution.  As such, you'll want to educate your users about how to use the request forms with this in mind.
  • This is the same for the "Resource Sharing Request" form used by staff in Alma to place a request on behalf of a patron.

In Alma, when entering or scanning a barcode results in an incomplete barcode number, items at other institutions may be charged to a patron.

  • Some I-Share institutions use sequential barcodes that are unique within the institution only.
  • The Automated Fulfillment Network is able to identify any item across the network by its barcode.
  • If a library scans a barcode, but the scan misses some of the digits--e.g., only the numbers after the library's prefix, or only the last four digits--if the entered number matches an item barcode in the network, that item will be charged.
  • Current Workarounds:
    • When scanning items in the Manage Patron Services screen, if a different item is charged than the item in hand, get the barcode from the screen, and discharge it on the return items screen. Contact the library whose barcode it was errantly scanned to let them know the item is now "in transit" back to their institution.
    • Consider asking systems staff to program barcode scanners to not automatically include a carriage return. Have circulation staff visually compare the barcode entered to the barcode scanned before clicking the OK button.
  • Workflow:
    • Contact the item's home library to inform them of the mis-scan.

Unfortunately, when a patron whose home library is not yours requests to pick up material from another I-Share library at your institution, Alma does not display which institution they belong to.

  • We have an Idea Exchange enhancement request for this issue, but it needs more support before it may be considered for development:
    • Any library staff member can set up an Idea Exchange account to submit ideas for development, vote on ideas already submitted, and add comments to give an idea more weight. Please consider creating an account and voting/commenting on this issue.
  • Workflows:
    • The patron should receive an "on hold" letter from the item's library when you scan it in for hold. Then when the patron arrives to check out the item, they should have their ID with them to let you know which institution they belong to.
      • Steps for checking out material to a patron from another I-Share library are on the How To: Fulfillment in Alma page under the section "How to bring up a patron record and check items out."
    • If you're doing contact-less pickup and need to check the item out to the patron before they arrive, unfortunately, the only way to know which patron has requested the item is to contact the item's library.
      • The item's home library can search for the item by barcode, and then select the "Requests" indicator to see the requesting patron's information.
      • The item's home library should provide your library with the patron's affiliation, so that you, as the pick-up library can complete the charge transaction.
        Screenshot shows an example item retrieved by barcode in the item's home library using a Physical Items search. The field "Requests" is highlighted to show that is what to select for the item's home library to locate the requesting patron.

When a user from one I-Share institution borrows or requests material from another I-Share institution, Alma copies some details in the user record from the patron's home library to the other I-Share library. That copy is called a "linked user record"; in Voyager, we called it a "stub."

  • The linked user record is "refreshed" with a new copy from the patron's home institution when specific scenarios occur:
    • Library staff to do a Fulfillment> Manage Patron Services> Find user in other institution re-import/re-save of the patron's home record.
    • If the user places another request for another item from the institution where the linked user record is saved.
    • In Primo VE, if the user selects the institution from the list of institutions in their account, their linked user record will be refreshed in Alma at that institution. (New with March 2021 release)
  • At the beginning of each month, the CARLI office runs a job to update only the expiration date in the linked user records.
    • The job run by the CARLI Office does not update any other data from the patron's home record, only the expiration date.
  • Please vote on this Idea Exchange for this topic.
  • Materials to be returned to Robert Morris University (RMC) can be returned to Roosevelt University (ROU).
  • Materials to be returned to MacMurray College (MMC) can be returned to the Illinois State Library (ISL).