1106 results found

1. Alma APIs Multilingual Code-tables

   We’d like to request an enhancement to the Alma API that would allow PUT and POST requests to include translation updates. Currently, only GET requests support the lang parameter for retrieving localized data, while updates ignore these descriptions. Enabling translation updates via API would streamline content management across languages, making it easier to keep localized information current and consistent.

   Updating code tables for around 80 patron-facing letters in three different languages via the web UI is extremely time-consuming and inefficient. Allowing translation updates through the API would greatly improve this process, making Alma more effective for multilingual institutions.

   We’d also like to highlight an inconsistency: the addressFrom field, which represents an email address, is language-dependent in the current setup. Since email addresses are universal and not language-specific, it would make more sense for this field to remain constant across all languages.

   Allowing language-neutral fields like addressFrom to remain consistent would simplify multilingual management and avoid unnecessary duplication across language settings.

   We’d like to request an enhancement to the Alma API that would allow PUT and POST requests to include translation updates. Currently, only GET requests support the lang parameter for retrieving localized data, while updates ignore these descriptions. Enabling translation updates via API would streamline content management across languages, making it easier to keep localized information current and consistent.

   Updating code tables for around 80 patron-facing letters in three different languages via the web UI is extremely time-consuming and inefficient. Allowing translation updates through the API would greatly improve this process, making Alma more effective for multilingual institutions.

   … more

   20 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  APIs and Integrations  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Linked Data Enrichment Moves $e Relator Subfields to Incorrect Positions When Saving Authorities with F3

   When saving a name authority record in Alma using the F3 function, the Linked Data Enrichment process is causing the $e relator subfield to move to an incorrect position within the field. Instead of maintaining the expected order (e.g., $a, $e, $1), the $e subfield is often placed at the end or in another unexpected location after $0/$1 subfields are added. This disrupts the intended structure of the authority field and creates extra manual work for cataloguers.

   Attempts to correct the placement by copying and pasting the $e subfield do not work as expected—Alma consistently pastes it at the end of the field, regardless of cursor position. This issue only occurs after Linked Data Enrichment and does not affect other fields or occur before enrichment.

   Ex Libris support has indicated that this is currently by design, as part of the Preferred Term Correction (PTC) process.

   Impact:
   • Authority records are not formatted as cataloguers expect, leading to confusion and extra manual editing.
   • The copy-paste function does not work reliably for $e subfields after enrichment.
   • The current behaviour reduces efficiency and increases the risk of errors in authority data.

   Request:
   Please review and enhance the Linked Data Enrichment and F3 saving process so that $e relator subfields retain their correct position (immediately after $a) when new $0/$1 subfields are added. Additionally, ensure that copy-pasting subfields works as expected in all scenarios. This change would improve cataloguing accuracy and workflow efficiency.

   When saving a name authority record in Alma using the F3 function, the Linked Data Enrichment process is causing the $e relator subfield to move to an incorrect position within the field. Instead of maintaining the expected order (e.g., $a, $e, $1), the $e subfield is often placed at the end or in another unexpected location after $0/$1 subfields are added. This disrupts the intended structure of the authority field and creates extra manual work for cataloguers.

   Attempts to correct the placement by copying and pasting the $e subfield do not work as expected—Alma consistently pastes it at the end… more

   80 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   4 comments  ·  Metadata Management  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   AdminErez Shabo (Product Manager, Ex Libris) responded

   Can you please confirm whether the $e subfield is always expected to appear before $0 and $1 in your workflows? If this is consistently the case, it may be possible to address the issue using an XSL normalization rule to automatically position the $e subfield before these subfields.

3. Printed history of invoice IN PDF FORMAT as proof of approval - for audits

   Printed history of an invoice is accepted as an official approval for audits.
   History output can be downloaded only in excel now, which can be overwritten manually in excel, that does not support the audit reason.
   My request is that history of an invoice should be downloaded in pdf format too which should be unchangeable.

   9 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Acquisition - Invoices  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

4. Add Shelving Location to "Monitor Requests & Item Processes"

   It would be extremely helpful to have the shelving location show up in the information on the "Monitor Requests & Item Processes" (MR&IP) lists. Neither "Pick from Shelf" (PFS) or MR&IP shows all of the most helpful information when fulfilling requests. The closest for our library's purposes is MR&IP with the only piece of information missing being the shelving location of items. If it could be added as an option or at least show up in the exported Excel sheet as a column that would remove a ton of extra time and labor for our fulfillment processes.

   12 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Fulfillment - Requests  ·  Delete…  ·  Admin →
   Closed  ·  AdminErez Shabo (Product Manager, Ex Libris) responded

   Hello All,

   This idea has been closed as part of a cleanup process for ideas older than two years with fewer than 20 votes.

   This cleanup process is necessary to streamline our idea management process and ensure that the most relevant and impactful ideas receive the attention they deserve. If you still feel strongly about this idea, you may submit it via the NERS process.

   We value your feedback and encourage you to continue submitting and voting for ideas that you believe will enhance Alma.

   Alma Product Team

5. Enable us to display items in an "Unavailable" location type as Unavailable in Primo

   We need the ability to show items that are assigned to a location with Type = UNAVAILBLE to show as unavailable in Primo

   The primary use cases that prompt this idea are:
   1. A library is closed for renovation and the items are inaccessible to staff and patrons, but the items must still be discoverable so that patrons can be directed to Resource Sharing in Primo.
   2. Portions of a collection are temporarily inaccessible to staff and patrons, and the items are assigned to a temp location, but must still be discoverable so that patrons can be redirected to Resource Sharing in Primo.
   In both of these use cases, setting the Location(s) to type = UNAVAILABLE accomplishes both suppressing a link for local requesting, and allowing a Request for Resource sharing link to appear, without any other configuration changes

   Right now, items that are in a type=UNAVAILABLE location show in Primo with a prominent "Available" indicator in several places, and use the label for c.uresolver.getit2.item_list.status.ITEM_IN_PLACE in ViewIt, even though the items are not actually available. There is no way to use existing functionality to suppress this "Available" label or the "In library" (ITEM_IN_PLACE) label without an unreasonable amount of work (see info on the impracticability of using work orders below)

   What is needed:
   1. The calculated availability for items in a type=UNAVAILABLE location needs to be Unavailable/Not Available, when Alma might otherwise consider the items to be "in place" (not on loan, not in a process, etc)
   2. The ViewIt information for items in a type=UNAVAILABLE location needs to use a new label, and not the "c.uresolver.getit2.item_list.status.ITEM_IN_PLACE" label

   Why the suggestion on the closed Idea 46262368 "make location type 'unavailable' functional: items in these locations should be shown as unavailable in Alma and Primo" (see URL below) of using work orders to accomplish this is unworkable:
   1. Work orders cannot be removed in bulk. If there are 300000 items that needs to be set to UNAVAILABLE, removing 300000 work orders manually when they are available again is an enormous burden on staff, and is practicably impossible.
   2. Patrons find the Primo display of items in work orders to be confusing
   3. Items in work orders are requestable unless further changes are made to the items or to configurations. Using a type=UNAVAILABLE location accomplishes the un-requestability without needing to do any other configuration or data changes,

   SUMMARY:
   Give us the ability to show items in a type=UNAVALABLE location as unavailable in Primo
   - enabling clear and understandable display of an item's availability to our patrons
   - without onerous additional work

   Note: this is basically a repost of https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/46262368-make-location-type-unavailable-functional-items
   That idea was closed despite support for the idea, and despite the unworkability of the "just put them in a work order" response from Ex Libris

   We need the ability to show items that are assigned to a location with Type = UNAVAILBLE to show as unavailable in Primo

   The primary use cases that prompt this idea are:
   1. A library is closed for renovation and the items are inaccessible to staff and patrons, but the items must still be discoverable so that patrons can be directed to Resource Sharing in Primo.
   2. Portions of a collection are temporarily inaccessible to staff and patrons, and the items are assigned to a temp location, but must still be discoverable so that patrons can be redirected to Resource… more

   •  

   288 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   11 comments  ·  Resource Management - Physical  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating
   AdminTamar Fuches (Alma product manager, Ex Libris) responded

   Dear colleagues,

   Thank you for raising this idea.

   This was part of the CERV cycle in 2025, but did not make it to the final list.

   During the analysis, 3 possible approaches were discussed, each has a different estimation and effort:

   Option 1: New dedicated process type

   • It will be possible to mark specific items as "unavailable", similarly to the way it is possible to mark them as "missing"
   • Items marked as "unavailable" will be considered as "not in place"
   • The new "unavailable" option will appear as a possible process type in all the places where there is a list of process types, including configuration options such as Fulfillment Unit Rules

   Option 2: Mark a location as "unavailable"

   • It will be possible to mark a location as "unavailable"
   • All items in this location will be considered as "not in place"
   • The difference from option 1 is that when an item is in an "unavailable" location, it can still be in a process such as loan, work order or any other process type. These are 2 separate attributes
   • The existing options for location based configuration can be used

   Option 3: A new "unavailable" field in item level

   • It will be possible to mark specific items as "unavailable", similar to the availability status of portfolios
   • Items marked as "unavailable" will be considered as "not in place"
   • Similar to option 2, "unavailable" item can still be in a process such as loan, work order or any other process type. These are 2 separate attributes
   • As this is a new attribute, relevant configuration options will need to be enhanced to take this attribute into consideration. Further analysis will be needed here

   Although option 3 might give more flexibility, it is super complicated and would require huge effort. Therefore, the selected option is option 2: Mark a location as "unavailable".

   The description of this idea exchange sounds like this option, however in the comments I saw some references to option 3. Therefore I wanted to share with you the analysis and discussion - you can see it in: https://public.3.basecamp.com/p/ERLrkhNUHtTYerEiaQAsG2uT

   Please note that as this did not make it to the final list of the CERV selected items, there is no timeline for implementing this.

   Thanks,

   Tamar Fuches

   Alma product team

   Dear colleagues,

   Thank you for raising this idea.

   This was part of the CERV cycle in 2025, but did not make it to the final list.

   During the analysis, 3 possible approaches were discussed, each has a different estimation and effort:

   Option 1: New dedicated process type

   • It will be possible to mark specific items as "unavailable", similarly to the way it is possible to mark them as "missing"
   • Items marked as "unavailable" will be considered as "not in place"
   • The new "unavailable" option will appear as a possible process type in all the places where there is a list of process types, including configuration options such as Fulfillment Unit Rules

   Option 2: Mark a location as "unavailable"

   • It will be possible to mark a location as "unavailable"
   • All items in this location will be considered as "not in place"
   • The difference from option 1 is that when an item… more

6. Significant Improvements to the 'Browse Shelf List' Function Needed

   The 'Browse Shelf List" function is essential for catalogers in our library and is extremely clunky and time-consuming to use. Proposing any (hopefully all) of the following changes:

   1. Ability to view more results surrounding the exact search request.
      Said in a different way, the ability to view the result in the middle of the results page, so as to be able to see a few of the results both before and after. This makes call number adjustment significantly easier, instead of always needing to click a back button and remember what the call number were on the page before.

   2. Ability to view shelf-list in Primo with one click.

   3. Ability to actually be able to see the entire call number in the call number field (see screen shot with blue arrow).

   If I need to type the call number by hand, or edit it at all, it is very difficult to see the entire thing or use this field if it cuts itself off.

   1. Removal of the need to click into the call number field to search the shelf listing.

   2. Ability to search the shelf list by call number that ignores sub-field labels.

   It appears to me that “Browse Shelf Listing” is done only against the 050 field in a bib record and only against the subfield “a” in that 050 field. This greatly limits the usefulness of this tool.

   Not to mention, call numbers can be found in 099 and 090 fields, requiring copy paste.

   Thus, the only way to search the shelf list accurately is to copy and paste the call number into that tiny, tiny box, then edit out the $$a, $$b, $$h and so on. This is a painful experience on 20+ books a day.

   The 'Browse Shelf List" function is essential for catalogers in our library and is extremely clunky and time-consuming to use. Proposing any (hopefully all) of the following changes:

   1. Ability to view more results surrounding the exact search request.
      Said in a different way, the ability to view the result in the middle of the results page, so as to be able to see a few of the results both before and after. This makes call number adjustment significantly easier, instead of always needing to click a back button and remember what the call number were on the page before.

   2. … more

   •  

   221 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   21 comments  ·  Resource Management - Physical  ·  Delete…  ·  Admin →
   Completed  ·  AdminErez Shabo (Product Manager, Ex Libris) responded

   The Alma Browse Shelf Listing enhancements are completed.

   This includes the following:

   1. Author information will be displayed in the browse results, to assist in adding call number cutter for libraries that use author information for this.

   2. Call number auto-population will also work for local 09X fields.

   3. Read-only access was added, so that all users can now browse shelf listing (similar to browse bib and authority headings)

   For more information please refer to the online help for Browse Shelf Listing.

7. Resource Sharing Partner: Contact Information and Parameters tab (multiple e-mail addresses)

   In the Alma documentation it is noted that the Contact tab of a Resource Sharing Partner is currently not functional:
   https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/050Resource_Sharing/005Managing_Resource_Sharing_Partners/010Resource_Sharing_Partners
   "In the Contact Information tab, add address, phone number, and email information for the resource sharing partner (for informational purposes only; information for sending the resource sharing request is entered in the Parameters tab – see the following step). For instructions, see Adding User Contact Information."

   The options (Email types) on the tab correspond to those of an Acquisition supplier (on the Vendor level and the Account level), but have not yet been implemented functional for Resource Sharing Partners. However, there is a great need for it.

   We have several Partners with different e-mail addresses for e.g. ordering and claiming or sending queries.
   So we would be glad, to have the full functionality for all Email types (Order, Claim, Payment, Queries, Returns) on the Contact tab as it is already the fact for Vendors (Acquistion).

   Currently for all ILL letters Alma used the e-mail address from the Parameters tab only.
   An also on this tab an enhancement is needed. It would be fine if you could define two e-mail addresses:
   - one for Lending Requests
   - and the other for Borrowing Requests
   because some Partners use diffent e-mail addresses for Lending and Borrowing requests and this enhancement would prevent unnecessary e-mail forwarding to the Partner libraries.

   Thank you in advance!

   In the Alma documentation it is noted that the Contact tab of a Resource Sharing Partner is currently not functional:
   https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/050Resource_Sharing/005Managing_Resource_Sharing_Partners/010Resource_Sharing_Partners
   "In the Contact Information tab, add address, phone number, and email information for the resource sharing partner (for informational purposes only; information for sending the resource sharing request is entered in the Parameters tab – see the following step). For instructions, see Adding User Contact Information."

   The options (Email types) on the tab correspond to those of an Acquisition supplier (on the Vendor level and the Account level), but have not yet been implemented functional for Resource Sharing Partners.… more

   30 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Resource Sharing  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

8. Change pickup location for hold when on hold shelf

   When a book is already on the hold shelf at Library A but a patron wants to pick it up at Library B instead, we should be able to edit the request to make that change.

   Currently, the hold must be cancelled and then re-requested with the new pick-up location. This can be an issue in the event there is another request on the item or the item needs to go back to a different library.

   5 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   1 comment  ·  Fulfillment - Requests  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

9. Add the Lender's mailing address to the Resource Sharing Receive Slip Letter xml

   Adding this xml to the letter code would allow us to print the Lender mailing address on our Resource Sharing Receive Slip Letter. This would help us be more efficient by printing just this single letter at the time this item is received, as we normally would. Then, when our patron returns the item with the slip, we won't have to physically print out the mailing address, and can use the slip already enclosed in the book.

   For example, this xml info is included in the Ful Resource Sharing Request Slip letter in the following fields: "notificationdata/partnershippinginfolist/partnershippinginfo/address1" and address2, 3, 4, 5 etc. and /partnershippinginfo/city , state, and postal_code.

   With those lines, we created a mailing label for our outbound resource sharing requests to print on our pull slips, which has increased our efficiency. We're wanting to do the same with our receive letter.

   Adding this xml to the letter code would allow us to print the Lender mailing address on our Resource Sharing Receive Slip Letter. This would help us be more efficient by printing just this single letter at the time this item is received, as we normally would. Then, when our patron returns the item with the slip, we won't have to physically print out the mailing address, and can use the slip already enclosed in the book.

   For example, this xml info is included in the Ful Resource Sharing Request Slip letter in the following fields: "notificationdata/partnershippinginfo… more

   20 votes

   Vote 0 votes Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Other  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

10. Improve OpenURL generation to remove blanks and duplicates

    Openurls generated could by Alma/Primo be shorted by:

    1. Not sending duplicate parameters.
    2. Not sending empty parameters.

    Background:

    We have noticed that OpenURLs produced by Alma/Primo (which are then sent on to our ILLiad server, which can require redirection to get the patron authenticated) can be VERY long. So long in fact, that they can produce errors for our ILLiad web server. The ILLiad server will end up reporting "Request header is too large", and the user is left with a HTTP Status 400 Bad request error.

    We believe the responsibility here is on the Alma/PRimo side as the urls generated could be shorted by:

    1. Not sending duplicate parameters.
    2. Not sending empty parameters.

    Note: For our (UW-Madison's) locally developed discovery interface, we generate our own OpenURL links for things like "Request a copy" from article searching and the catalog records, so we can ensure proper length limits.

    ExLibris generates OpenURL links in their UResolver (Find it) and Primo Search API

    Alma/Primo OpenURLs

    For example, following a "Find it at UW-Madison" link from Google Scholar and then doing "Request a copy" (sending the OpenURL on to our ILLiad server):

    Starting in Google Sholar, and ending up here:
    https://uwi-primoalma-prod.hosted.exlibrisgroup.com/primo-explore/openurl?sid=google&auinit=PM&aulast=Vitousek&atitle=Beyond%20global%20warming:%20ecology%20and%20global%20change&id=doi:10.2307%2F1941591&title=Ecology.&volume=75&issue=7&date=1994&spage=1861&issn=0012-9658&vid=WISC&institution=WISC&url_ctx_val=&url_ctx_fmt=null&isSerivcesPage=true

    Provides an OpenURL link (request a copy) of:

    https://madison.hosts.atlas-sys.com/illiad/OpenURL?Action=10&Form=30&rft.genre=article&rft.title=Ecology.&rft.stitle=Ecology.&rft.atitle=Beyond+global+warming%3A+ecology+and+global+change&rft.jtitle=Ecology.&rft.au=&rft.date=1994&rft.month=&rft.volume=75&rft.issue=7&rft.number=&rft.spage=1861&rft.epage=&rft.edition=&rft.issn=0012-9658&rft.eissn=1939-9170&rft.aulast=Vitousek&rft.aufirst=&rft.auinit=PM&rft.pub=Brooklyn+Botanical+Garden&rft.pubdate=1920-&rft.pubyear=&rft.publisher=Brooklyn+Botanical+Garden&rft.place=Brooklyn%2C+NY+%3A&rft.doi=10.2307%2F1941591&rfe_dat=35698209&rfr_id=google

    Where the following parameters are included, yet blank:

    au, month, number, epage, edition, aufirst, pubyear

    Primo Search API

    In order to display electronic availability for articles we have to query the OpenURL resolver in alma to get data back. The string we use to query the resolver is provided to us by the Primo Search API

    Primo API Docs - Ex Libris Developer Network

    This one is by far the biggest offender, as that API returns the "GetIt1" URL we need to use. An example URL returned to us looks like:

    https://na02.alma.exlibrisgroup.com/view/uresolver/01UWI_MAD/openurl?svc_dat=CTO&ctx_enc=info:ofi/enc:UTF-8&ctx_id=10_1&ctx_tim=2020-02-07T10%3A04%3A19IST&ctx_ver=Z39.88-2004&url_ctx_fmt=info:ofifmt:kev:mtx:ctx&url_ver=Z39.88-2004&rfr_id=info:sidprimo.exlibrisgroup.com-proquest&req_id=&rft_val_fmt=info:ofifmt:kev:mtx:journal&rft.genre=article&rft.atitle=Telltale%20warming%20likely%20to%20hit%20poorer%20countries%20first&rft.jtitle=Nature&rft.btitle=&rft.aulast=Schiermeier&rft.auinit=&rft.auinit1=&rft.auinitm=&rft.ausuffix=&rft.au=Schiermeier,%20Quirin&rft.aucorp=&rft.date=2018-04-26&rft.volume=556&rft.issue=7702&rft.part=&rft.quarter=&rft.ssn=&rft.spage=415&rft.epage=416&rft.pages=415-416&rft.artnum=&rft.issn=00280836&rft.eissn=14764687&rft.isbn=&rft.sici=&rft.coden=&rft_id=info:doi/10.1038d41586-018-04854-2&rft.object_id=&rft.eisbn=&rft.edition=&rft.pub=Nature%20Publishing%20Group&rft.place=London&rft.series=&rft.stitle=&rft.bici=&rft_id=info:bibcode&rft_id=info:hdl&rft_id=info:lccn&rft_id=info:oclcnum&rft_id=info:pmid&rft_id=info:eric((addataeric}}&rft_dat=%3Cproquest%3E2056433252%3Cproquest%3E%3Curl%3Ehttp:search.proquest.com/docview/2056433252/%3C/url%3E,language=eng,view=MD&svc_dat=viewit&req.skin=MADskin&rft_pqid=2056433252&rft_galeid=572639507&rft_cupid=&rft_eruid=&rft_nurid=&rft_ingid=

    Previously we ran this URL through a parser to validate it and then remove empty parameters. There are three issues with this data - 1) sometimes keys are duplicated, which goes against best practices 2) Data is not properly url encoded 3) There are a lot of empty parameters.

    Removing those parameters for this example request would drop the length of the URL from 1328 to 1052 characters

    Note: We no longer parse this data as it was dropping the duplicated parameters causing lookup issues, so it's passed through to our OpenURL resolver as we receive it from the API (aside from prepending a parameter to return XML instead of HTML)

    Openurls generated could by Alma/Primo be shorted by:

    1. Not sending duplicate parameters.
    2. Not sending empty parameters.

    Background:

    We have noticed that OpenURLs produced by Alma/Primo (which are then sent on to our ILLiad server, which can require redirection to get the patron authenticated) can be VERY long. So long in fact, that they can produce errors for our ILLiad web server. The ILLiad server will end up reporting "Request header is too large", and the user is left with a HTTP Status 400 Bad request error.

    We believe the responsibility here is on the Alma/PRimo side as the urls… more

    16 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Resource Management - Electronic  ·  Delete…  ·  Admin →
    Closed  ·  AdminLiza Voloshin (Product Owner, Alma Resource Management, Ex Libris) responded

    Hello all,

    This idea has been closed as part of a cleanup process for ideas older than a year with fewer than 20 votes. This cleanup process is necessary to streamline our idea management process and ensure that the most relevant and impactful ideas receive the attention they deserve. If you still feel strongly about this idea, you may submit it via the CERV process. We value your feedback and encourage you to continue submitting and voting for ideas that you believe will enhance Alma.

    Alma Product Team.

11. Support file exchange via Odyssey

    While we are able to send and receive files with other Alma, Rapido, and RapidILL libraries via RapidX, the resource sharing world is much larger than these three systems. While ExLibris talks about supporting interoperability, we are not yet able to receive files using the file sharing method dominant among our peers, even though its platform is open source. Odyssey is a major player in the library secure file exchange world, and while we stress to our partners that they need to send non-returnables to us via other methods, often folks forget, deliver via Odyssey, and assume the request is filled. As the borrowing library, we don’t notice these files haven’t come through until an unreasonable amount of time has passed and we check in with the other library. Meanwhile, our patrons could have had these files the whole time - and in some cases, by the time we catch it, it’s past the patron’s deadline. Please build in the ability to receive files via Odyssey when using ISO to communicate with other libraries through Alma Resource Sharing & Rapido

    While we are able to send and receive files with other Alma, Rapido, and RapidILL libraries via RapidX, the resource sharing world is much larger than these three systems. While ExLibris talks about supporting interoperability, we are not yet able to receive files using the file sharing method dominant among our peers, even though its platform is open source. Odyssey is a major player in the library secure file exchange world, and while we stress to our partners that they need to send non-returnables to us via other methods, often folks forget, deliver via Odyssey, and assume the request is… more

    35 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Resource Sharing  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

12. Allow filtering and sorting on all columns in "In process items"

    In the "In process items", some columns can be filtered (Process status, request filter, library) and some can be sorted but not all. It would be useful to be able to filter by "Modified by", "Modification date" and to sort by "Modification Date".

    7 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Other  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

13. include cancellation note in create digitization cancellation email

    If a create digitization request on a lending request is cancelled, the explanation/message from the library/stores team is not included in the cancellation email to the lending partner.
    It would be nice if this went into the cancellation email as an extra bit of information explaining why the request has suddenly been cancelled.
    When the ILL Team cancel a request, we usually give a bit of an explanation, like missing from shelf, missing pages, too fragile, etc.

    3 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Resource Sharing  ·  Delete…  ·  Admin →
    Closed  ·  AdminMoshe Shechter (Alma Senior Product Manager, Ex Libris) responded

    Thank you for taking the time to share your idea with us. We truly appreciate your engagement and the thought you put into your suggestion.

    While we initially hoped it might align with broader needs, the idea has not gained the traction we typically look for to prioritize development. As a result, it’s unlikely to be pursued in the foreseeable future.

    That said, your feedback remains valuable, and we’re grateful for your contribution.

14. Add column to Patron service on the Loan-tab which shows that the item has been requested by another user

    Our fulfillment department often gets phone calls of patrons who do not understand why their loan can not be renewed. Now we have to click the View queue in Actions to check this, but it would be much more convenient to see in a blink of an eye that there are requests immediately on the loan tab.

    25 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    2 comments  ·  Fulfillment - General  ·  Delete…  ·  Admin →
    Already Supported  ·  AdminMoshe Shechter (Alma Senior Product Manager, Ex Libris) responded

    Two columns in the Manage Patron Services page display the most recent status and date for the item if any renewal has been attempted. See https://knowledge.exlibrisgroup.com/Alma/Release_Notes/0099_2017/100_March_2017/Alma_March_2017_Release_Notes/04Fulfillment_-_March_2017_Enhancements#Renewal_Enhancements_in_Manage_Patron_Services

15. Add Cancellation Reason code and Notes to the Interested In Letter XML

    This essentially replicates an earlier request that was closed in 2021 without resolution:

    https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/44262498-request-to-add-cancellation-reason-and-cancellatio

    We would like to have Cancellation Reason code and Cancellation Note available in the XML that is supplied to the Interested In letter template. The Cancellation Reason code is a distinct field In Analytics, so I would hope that this would be easy to add to the XML. The cancellation note might be trickier -- it is stored as a PO Line Note in Analytics. If the cancellation note is just one of several PO Line notes in Alma, we would be happy to have all the PO Line Notes go to the Interested In letter XML, though it would be better if the Cancellation Note was sent as a separate element in the XML.

    This essentially replicates an earlier request that was closed in 2021 without resolution:

    https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/44262498-request-to-add-cancellation-reason-and-cancellatio

    We would like to have Cancellation Reason code and Cancellation Note available in the XML that is supplied to the Interested In letter template. The Cancellation Reason code is a distinct field In Analytics, so I would hope that this would be easy to add to the XML. The cancellation note might be trickier -- it is stored as a PO Line Note in Analytics. If the cancellation note is just one of several PO Line notes in Alma, we would be happy to… more

    •  

    •  

    9 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Acquisition - PO & POLine  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

16. ability to track perpetual access to eJournals when you cancel them.

    submitted case #00086211 to create a new field in the Electronic Portfolio and Electronic Collection records for 'Perpetual Access Coverage Dates', and for this field to be retrievable in Alma Analytics.

    We use separate spreadsheets to track these cancelled titles. In Alma, we would update coverage end date, POL if applicable (for individually subscribed titles in our case), and also a public note indicating the discontinuation. Patrons contacted us and asked why they couldn’t access a title any more, so we figured a public note would be more helpful to patrons in this case. But the public note fields is not searchable. We’ll consider using the internal description field to track within Alma.

    We did not feel it appropriate to include this information in the licence record, as the perpetual access relates to multiple licence agreements depending on the history of the journal title.

    Ex Libris closed the case and reported that this enhancement request has been added to the Roadmap with no estimated timeline for the release.

    submitted case #00086211 to create a new field in the Electronic Portfolio and Electronic Collection records for 'Perpetual Access Coverage Dates', and for this field to be retrievable in Alma Analytics.

    We use separate spreadsheets to track these cancelled titles. In Alma, we would update coverage end date, POL if applicable (for individually subscribed titles in our case), and also a public note indicating the discontinuation. Patrons contacted us and asked why they couldn’t access a title any more, so we figured a public note would be more helpful to patrons in this case. But the public note fields is… more

    32 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    3 comments  ·  Acquisitions - General  ·  Delete…  ·  Admin →
    Already Supported  ·  Dana Sharvit responded

    Please see perpetual access best practice at:
    https://knowledge.exlibrisgroup.com/@api/deki/files/41819/perpetual_access_best_practice.pdf

17. Add User Statistical Categories as a Parameter in Fulfillment Units Rules

    We would like the ability to add user statistical categories as input parameters when configuring Fulfillment Units. This will allow us to apply additional terms of use (TOUs) to certain subsets of User Groups.

    Right now, we are able to configure Fulfillment Unit rules based on User Groups (i.e. Student, Staff, Community Member, etc.). However, there are certain subsets of users within these groups (for example, a student that is part of a scholarship program, learning community, or major) that we would like to apply different TOUs to. We can identify these users with Statistical Categories and if we could configure input parameters for Fulfillment Unit loan and request rules with these Statistical Categories, we would be able to apply the desired TOU for those users.

    Please add user statistical categories as a parameter in fulfillment unit rules for loans, requests, and bookings.

    See attached images. One shows a mockup of editing a parameter with “Statistical Category” as the name option, and values derived from the User Statistical Categories Code Table. The other shows a mockup of an example fulfillment unit loan rule relying on statistical categories.

    We would like the ability to add user statistical categories as input parameters when configuring Fulfillment Units. This will allow us to apply additional terms of use (TOUs) to certain subsets of User Groups.

    Right now, we are able to configure Fulfillment Unit rules based on User Groups (i.e. Student, Staff, Community Member, etc.). However, there are certain subsets of users within these groups (for example, a student that is part of a scholarship program, learning community, or major) that we would like to apply different TOUs to. We can identify these users with Statistical Categories and if we could… more

    •  

    •  

    29 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    Completed  ·  1 comment  ·  Fulfillment - General  ·  Delete…  ·  Admin →

18. Add a week key to dates eg request dates

    We would like to be able to look at physical item requests by week, but can only currently do it by month. Could a week key be added to analytics?

    1 vote

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    0 comments  ·  Analytics  ·  Delete…  ·  Admin →
    Completed  ·  AdminYoel Kortick (Senior Librarian, Ex Libris) responded

    In the ideas exchange " Add a week key to dates eg request dates" You ask:
    We would like to be able to look at physical item requests by week, but can only currently do it by month. Could a week key be added to analytics?

    We answer:
    This can be done using the “Request Date Week Number” in the Requests Subject Area.
    This field did not exist in 2017 when you opened the ideas Exchange.

19. Incoherent date in the “Date” column when the transaction type is “Expenditure”

    According to the developer, the expenditure date comes from the invoice date and always comes from it (see documentation at https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/030Invoicing/020Creating_Invoices).

    As you can see there, the calculation of the exchange rate is also done according to this date: "By default, Alma calculates the value of the transaction based on the exchange rate on the date specified in Invoice Date."

    Now we know where the date comes from when the type of transaction is “Expenditure”. However, in other types of transactions (transfer, allocation, encumbrance, etc.) the date that appears corresponds to the moment in which the transaction occurs. For this reason, it seems impractical that in the type of transaction “Expenditure” the invoice date is used and not the date on which the transaction is triggered, that is, the “create on” date.

    We request to incorporate a new column in the table of visualization of transactions that is “create on”.

    We provide explanatory screenshot of how it could be implemented.

    According to the developer, the expenditure date comes from the invoice date and always comes from it (see documentation at https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/020Acquisitions/030Invoicing/020Creating_Invoices).

    As you can see there, the calculation of the exchange rate is also done according to this date: "By default, Alma calculates the value of the transaction based on the exchange rate on the date specified in Invoice Date."

    Now we know where the date comes from when the type of transaction is “Expenditure”. However, in other types of transactions (transfer, allocation, encumbrance, etc.) the date that appears corresponds to the moment in which the transaction occurs. For… more

    •  

    •  

    32 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    1 comment  ·  Acquisition - Funds  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Submit Rating

20. Configuring different sender e-mail addresses (SMPT-envelope-from) for one letter-type

    For now the SMTP-envelope-from definition for Alma Letters can be set only once per letter-type. This isn’t suitable. E.g., our libraries need more than one sender email address for different acquisition departments. Vendors should be able to reply directly to the departments E-Mail-address. Using one no-reply-address (as SMTP-envelope-from value) in combination with a “reply-to”-addresses written in the Mail Footer cannot be a permanent solution.

    Actual situation in Alma:
    When an E-Mail is send in the context of a job Alma takes the SMTP-envelope-from value from the „addressFrom”-definition in the concerning letter-configuration (general configuration -> letter emails).
    When an E-Mail is send manually by a staff member (e.g. conversation letter, also used for claims to vendors) Alma takes the SMTP-envelope-from value from the definition in the settings for “preferred E-Mail-Address” of the acting staff member.

    Suggestion:
    ALMA already allows the definition of up to 5 E-Mail-Addresses of different types for each department or library (primary, billing, shipping, claim response, patron communication). Unfortunately these types can be used only as output-values in the letter-content (=text), but not as actual SMTP-envelope-from addresses. This function could be extended as follows:
    When E-Mails are send from a job or manually by a staff member, the values “from” and “Reply-to” in the SMTP-envelope section should be taken from a specific E-Mail-Address in the contact-definitions of the department (e.g. preferred). If no E-Mail-Address is defined in the concerning department the E-Mail-Address of the library and (if none defined) at least the E-Mail-Address of the institution should be taken (or even the value from „General Configuration - Configuration menu - General Configuration - other settings - envelope-from”).
    This improvement would give the whole system more flexibility not only for Acquisition-departments.

    (This is in addition to Ners request ID 5184)

    For now the SMTP-envelope-from definition for Alma Letters can be set only once per letter-type. This isn’t suitable. E.g., our libraries need more than one sender email address for different acquisition departments. Vendors should be able to reply directly to the departments E-Mail-address. Using one no-reply-address (as SMTP-envelope-from value) in combination with a “reply-to”-addresses written in the Mail Footer cannot be a permanent solution.

    Actual situation in Alma:
    When an E-Mail is send in the context of a job Alma takes the SMTP-envelope-from value from the „addressFrom”-definition in the concerning letter-configuration (general configuration -> letter emails).
    When an E-Mail is… more

    264 votes

    Vote 0 votes Vote Vote

    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    1 vote 2 votes 3 votes Remove votes

    You have left! (?) (thinking…)
    6 comments  ·  Other  ·  Delete…  ·  Admin →
    Completed  ·  Dana Moshkovits responded

    When sending patron notices from a library, the library's 'Circulation Communication' address will be used as the reply to address on the email. For more information see video at https://youtu.be/bFfopLgjEN4'