Related product I-Share

Alma/Primo VE Known Issues

Updated: 5/19/2022

General Alma Troubleshooting and Problem Reporting

expand / collapse all

Your users may see a change in Primo VE request behavior, see the “Notice for library staff” section below.
No configuration changes need to be completed by your institution; CARLI staff have made the configuration changes described below.

Reported issue:
Following the February Alma/Primo VE update, there was an increase in patron I-Share requests being automatically cancelled, when copies of the title should have been available to request.

The problem was caused by a change to how the Primo VE Resource Sharing Request form is pre-populating the “Preferred Local Pickup Location” field:

  • If an institution has more than one pick-up location for patron requests, the default pickup location that is set in Alma was not always prepopulating the box on the form in Primo VE like it used to. Users were able to submit requests without this necessary information; these patron requests were automatically cancelled by Alma.
  • If an institution only has one Local Pickup Location, that pick-up location is correctly prepopulating the Preferred Local Pickup Location form as expected. These patron requests were not affected as they contained the correct pick-up location information.

Configuration changes:
As a workaround to this issue, CARLI staff have updated all Resource Sharing Request forms for all I-Share institutions to make the “Preferred Local Pickup Location” be a mandatory field.
This will prevent patrons from inadvertently submitting requests with this field blank.

We have a ticket open with Ex Libris for investigation into why the default pick-up location field no longer pre-populates with the default pick-up location.

Notice for library staff:
Due to the workaround in place, if an I-Share patron is choosing to pick up their requests at an I-Share library that is not their home library, they may now be prompted to also set a “Preferred Local Pickup Location” in the request form.

This may cause confusion as the “Preferred Local Pickup Location” field contains the list of circulation desks at their home institution, not at their desired pick-up institution.
However, selecting the “Preferred Local Pickup Location” at their home institution will not affect their request; the requested item will still be delivered to their chosen I-Share institution.

Problem: In certain situations where Primo VE's deduplication mechanisms are grouping multiple bib records, and the record chosen for display is local to the IZ and not linked to either the NZ or the CZ, physical holdings attached to a the record that was not chosen for display may not display completely. The holdings will show the location and call number, but any other holding record data like 852 notes and 866 summary statements, or physical Items, do not display. Users are unable to request Items on such records because the request links are not triggered to display.

CARLI has filed a Case with Ex Libris to report this problem. There is currently no known workaround.  On 3/14/2022, Ex Libris notified CARLI that this would be fixed in the May 2022 release on May 1, 2022.

Problem: Although signed-in Primo VE users can add tags to items, if a user clicks on the tag link on the Full Details page for an item or if they click the link for a tag on the tags list via the Tags link in the Links Menu, a search for the term will run but no results will be provided.

At this time, Ex Libris does not provide the tag functionality for consortial users. CARLI recommends libraries turn tags off/do not enable the tag function. Directions on how to turn the tag function off can be found on the following page: Tags in Primo VE.

Problem: This only affects search results from the "All I-Share Libraries" search slot. If there are two bib records for different versions of a title--such as one electronic and one print--and the print bib is chosen for display in Primo VE by the Dedup process, the physical holdings from other I-Share libraries and the electronic access shared from the Network Zone are not displaying. This can cause the "Available Online" indication to appear on the Brief Results page and then disappear on the Full Record page in "All I-Share Libraries" searches.

CARLI has opened a high priority Case 06051166 with Ex Libris for investigation. Ex Libris has targeted a fix for August 2022.

Problem: Primo VE-generated APA citations are omitting the author’s first initial for records with single authors/creators and the first initial of the first author for records with multiple authors/creators. For example,
instead of:
Payne, S. G., Sorkin, D. J., & Tortorice, J. S. (2004). What history tells George L. Mosse and the culture of modern Europe . University of Wisconsin Press.
the generated citation is:
Payne, Sorkin, D. J., & Tortorice, J. S. (2004). What history tells George L. Mosse and the culture of modern Europe . University of Wisconsin Press.

CARLI has opened Case 06044300 with Ex Libris. Ex Libris is aware of this problem, and it is affecting all customers. This issue dependent on citation style language (CSL) files which are controlled by a third party. Ex Libris staff are working with those developers to get this addressed.

Problem: In the Citation action in Primo VE, the default label says "APA (6th edition)" but the version is actually the 7th edition of APA.

Primo VE is designed to always use the most recent edition of APA that is available, but the label itself is not updated automatically.  I-Share libraries can correct this display label by changing it from APA (6th edition) to APA (7th edition) in: Alma Configuration > Discovery > Other > Citation Styles > Edit "apa" and change the Label from "APA (6th edition)" to "APA (7th edition)".

We have also learned that this is a problem for all Citations provided in out-of-the-box Primo VE. The most recent version of the citation format is always being used by default, but the label is not automatically updated to reflect the current edition name.  The label must be changed manually in Alma Configuration > Discovery > Other > Citation Styles.  For more information on how to adjust these labels or add new citation styles, see the May 12, 2022 CARLI Alma Primo VE Office Hours "Lab Reports" where there was a session on citations!

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:

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 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; Ex Libris confirmed this behavior is expected.

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.

In Alma, the correct workflow to clear an AFN item with an expired hold is to go to the Alma> Fulfillment> Resource Requests> Expired Hold Shelf> Send to Institution tab, and then use the "Transit" options to put the item into the appropriate status and workflow for return to the item's home library.

However, if library staff instead use Fulfillment> Checkout/Checkin> Return Items for that item that has the expired hold, Alma will:
1) Remove the item from the Fulfillment> Resource Requests> Expired Hold Shelf list.
2) Produce a transit slip for the items' home library (albeit, the transit slip will contain both the item's home library, and the patron's pick up institution in the listing; see screenshot).
3) Will not fully clear the hold; when the item arrives at the item's library, Alma will prompt the staff to return it back to the patron's pick-up institution.
However, when it then arrives back at the pick-up institution, a new hold shelf slip does not print. Instead, Alma then prompts the library to send it back to the item's home institution.
The item is stuck ping-pong-ing back and forth until staff at one of the libraries is able to check it out the original requesting patron, and then return it.

Either the patron's home library, or the item's home library (whichever library has the item in hand) can charge the item to the requesting patron WITHOUT then clicking the Done button (since the patron no longer wants the item, so therefor does not need the letter knowing it was checked out to them). Once the item is checked out to the requesting patron, immediately return the item to remove it from the patron's account and prompt routing/re-shelving.

CARLI has filed Case 05332794 with Ex Libris; a fix is anticipated in May 2022.

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.

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