A comment or note field for configurations would be incredibly helpful in general, but the current pandemic has highlighted the need for a way to easily track the reasons behind changes. This would keep the notes in the places where they'd be seen by the people working on the configurations, rather than us having to track things in a separate place.

All of the fulfillment configuration menu would benefit from this ability when short-term or emergency changes are being made. But it would also be good in places like: Letters; DARA recommendations; and all Other Settings areas. These are places that we might only touch once a year or less, so it would be helpful to know why X was deactivated, or who asked for Y change in wording.

With CDI we have no control over preventing CDI content from appearing in our Primo filtered search, when we have full text holdings which matches to this content.
In many cases this may be a good thing, in not needing to worry over making sure full text content is searchable.
However, it is clear that there are collections in CDI with very poor data, which causes linking to fail, and also has content which we do not want at all such as Journals and Books, as we manage the title level by our Alma records.
For example, CRL Catalog has 76,000 Journal records, which duplicate our own records and many of them are failing Link Resolver requests. LIBRIS has similar issues and content, and so does DataCite.
In just one day of Link Resolver data, for CRL we had 17 of 49 requests fail (34%), and for DataCite we had 27 of 124 requests fail (21%).
These numbers are all real users who are having a poor experience in our Primo environment and building a terrible impression of our Library service.
We should be able to remove this content by Alma Electronic Collection, with this content not appearing in our Primo environment if the CDI Electronic Collection is not in our Alma environment, such as not in our Institution Zone, or a new CDI setting to achieve this.
Please restore our autonomy to remove this content, so that we can offer our users a stable and consistent experience.

When you manually request a particular SUSHI account/report to be harvested by Alma, by default Alma requests any data which it hasn't already loaded for that account from the last 12 months. If there are multiple months in sequence missing, Alma requests the data for these months together as a single SUSHI request.

This is an inflexible system.
Instead, at the point where a user requests a harvest, Alma should ask the user to specify the time period they would like to request.

This would have several advantages:

• We would be able to use SUSHI to harvest usage data from greater than 12 months ago.


• When troubleshooting data errors, we could ask Alma to harvest just a single month at a time.


• We could avoid duplicating usage data which has been loaded into Alma manually.


• We could avoid harvesting the most recent month's data if the vendor hasn't yet made it available.

Since some institutions have buildings with perpetual restricted access, we have some AFN fulfillment network member libraries that are willing to send their materials to another AFN member library for pick-up, but, for all functional purposes, they are closed to the public. They don't want patrons from the other AFN institutions to visit their library in person, and thus, don't want patrons from another AFN institution to select their library as a pick-up location.

This need has been heightened during the pandemic, with more institutions closed to the public.

We know that turning off all circ desk hold shelves will fully remove an institution from the list of pick-up locations visible in Primo VE; however, if an institution is allowing local requesting for their own patrons (including curbside delivery or for USPS mail delivery), then they need to have the hold shelf enabled.

We need a setting that would allow Institution A to lend/renew/borrow/request/fulfill-requests for Institution B, without allowing Institution B's users to select Institution A as a pick-up location.

Also, if Institution A will lend material to a patron from Institution B, we also need a way to prevent a patron from selecting Institution C as a pick-up location, if Institution C is not open to the public.

The functionality would need to be consistent for the patron for both local and AFN requesting, because it is difficult to teach patrons contingencies.

Hello to eveybody,
yesterday watching the webinar "The Alma New Metadata Editor - Webinar Sept. 08, 2020" we found out the in the add inventory there isn't the possibility to add an holding.
This is not useful for libraries that don't do the order in Alma, but simply add an holding after cataloguing a book.
The possibility of adding an holding from the menu View inventory should be present.
The Add inventory should have the default holding template included in the menu.
If the operator wants a specific template it is clear that the operator must choose the right holding template from the menu New and pick the template he wants.
We hope you can support our idea because the fact that the holding is not present in the add inventory menu (easier way to create an holding), but operators have to go in the New menu and choose the template can create confusion and errors.

Thank you Emanuela Pisanu - University of Siena

Dear all
the May release introduced a change concerning the deletion of empty holdings:

The 'Delete Holdings' link in the 'List of Holdings' page, which was formerly visible to users with the 'Physical Inventory Operator' role, is now visible only to users who have the 'Physical Inventory Operator Extended' role.

This change is a problem because not all the operators can have the physical Inventory Operator Extended role: this role allows operators to delete copies and it is quite dangerous.
It would be better for us that operators with the physical inventory role keep the permission to move copies from an holding to another and then delete the empty holding. (let’s think of a correction of call numbers)
We propose the creation of a second Physical Inventory Operators’ role :
One without the possibility of delete empty holdings
and another one with the possibility of delete them.
So that, according to the job that operators have to do, they could keep doing the work deleting empty holdings

Ex Libris says the Delete interested users job "Runs weekly to delete interested users that are linked to closed or canceled PO lines. The job checks that an interestedin letter was sent to the interested users before removing it from the PO Line. Interested users will not be removed from a closed or canceled PO line if a letter was not sent to them."

Due to privacy regulations, we would like the job to run regardless of a letter being sent or not. The closed or cancelled PO line should be sufficient to run the job.

We do not use the Interested user letter for e-books since it doesn't include either URL to Primo or direct URL, which would be even better. To give separate votes to the improvements to the letter, please go to: https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/13113015-add-more-work-record-details-e-g-mmsid-to-the-i

User experience testing that we conducted showed that most users prefer to place resource sharing requests via the resource sharing request form in Primo. Users also expressed frustration with some aspects of the form including the format of the fields. They also expected that the Library could add notices relevant to the resource sharing service to this page.

The current options for configuring this form do not allow us to meet the expectations of our users. We would like to have more options for customising the page the form is on and the form itself. Specifically we would like :
1)The ability to customise the format and appearance of the page (e.g. the width of form fields, the positioning of the radial buttons)
2)The ability to add a notice or message to the form (this is crucial to communicate important information about the service to our users)
3)The ability to add custom fields to the form

Acquisitions --> Receive --> Continuous (orders) --> Manage Items

We would be happy to have additional fields in the 'Received Items List':
- Internal note 1
- Internal note 2
- Internal note 3
- Public note

Our colleagues in the Serials Department use Item Notes to document vendor responses (of reminded issues) or for notes that only concern individual issues. Having these information already displayed in the list without additional clicks would make their daily work much easier.
Since display in the "Manage Items" list is configurable, each customer can decide for herself/himself which fields she/he would like to have displayed.

Configuring Alma to deliver an exclusively off-campus service in response to the Coronavirus pandemic included the extension of due dates for us. We were thankful for the 'Bulk Change Due Dates' functionality, which we were able to use to push back the due dates of a majority of items on loan (until 1 June in the first instance for us). We encountered problems though when it came to any items borrowed by patrons whose records were due to expire before that date. The items wouldn't go beyond the patrons' expiry dates, which under normal circumstances would be exactly how we would have Alma work, but in this situation was inconvenient and required us to do a manual workaround. Likewise, the due dates of any items on loan that had been recalled due to policy (e.g. having reached the end of the maximum renewal period) or requests were not extended, so again we had to deal with those separately.

Recognising that the way Bulk Change Due Dates works currently is suitable for Alma users probably a majority of the time, could tick-box options such as 'Disregard patron record expiry dates' and 'Include recalled items' be added to that screen please?

Alma Process Types and the associated Base status of 'Item not in place' are hardcoded, as are the automated workflows within Alma and the flow-through to Primo for the availability to be set to 'Not Available'.
This is extremely limiting and there are scenarios when a Library might want their physical resources to still be discoverable in Primo ie not suppressed, but also be marked as Unavailable, such as if there were a temporary mould outbreak. This ensures that users are aware that we hold resources already, so they don't waste time submitting purchase requests or thinking that we have a poor collection, while also avoiding confusion with resources set to 'Available', when the Library does not want them to be.
Ideally, there would be a configuration option available whereby a site could configure a new Process Type, as a static status with no associated automated workflows, add their own label for the Get It display, and be able to run the Change Physical Items job against sets to set this Process Type to add it and also remove it (as can be done now with the Missing process type).
This would then flow through immediately to Primo to mark these resources to be 'Unavailable' by the availability status, and display the associated label in the Get It by RTA (Real Time Availability).
These configurable Process Types would also be added to Analytics, along with the existing hardcoded Process Types, in the Physical Items subject area, for tracking and ease of handling.

This copy option was introduced in the November 2019 release: Authority Contribution – Copy Option:

For institutions that are authorized to contribute authority records to the Community Zone, there is a new Record View page action (Copy to Community) that enables you to easily copy an authority record to the MD Editor, edit and save it, and contribute the saved record to the Community Zone and an external authority system such as GND, BARE, or NLI. The Copy to Community action appears when you select a title to view from your Authorities search results on the Community tab. See Copy to Community for more information.

We very much welcome this feature. The current functionality, totally detached from the cataloging process, makes it however a lot less useful than expected. We suggest ExLibris redesign the functionality to better make it support our daily cataloging workflow:

• When authorizing a heading during cataloging in the MDE (F3), an option to search for external authorities, much like the "Search Resources"-functionality, should appear.

• There is a need for matching, merging, normalizing and filtering the authority records in the same way as for the bib.records we import by use of "Search Resources". It should be possible to have different import profiles for the different sources.

There are lots of tables in the Alma UI that come up which can be sorted by a couple of the column heads but not others. For example in Letters Configuration, you can sort by "Letter" or "Description," but not by "Enabled," "Channel," or "Retention Period." Being able to sort by column headings is a basic function of a table.

In the example above, it would be helpful to be able to see only those letters that are enabled, or to sort so that all the email letters are grouped together and all the SMS letters are separate from them.

So much of what we do in Alma is arranged in tables like this, so it would be great if they could be made more user friendly.

We have repeatedly run into issues with the following: Things implemented in the Alma UI are not automatically available via API and/or Analytics.

Recent examples include:
* June 2020 "Can't edit restricted users" - Ex Libris offered to add this to the API, but not to Analytics
* CDI Search activation status - as of now it is not clear whether we will have access to this via API

To be honest: I am not willing to open an idea or NERS every time Ex Libris thinks it's nice to have something in the Alma UI, but do not care to implement for the API and/or Analytics. And I thought: Maybe neither are you.

There might be cases where it actually makes sense to add a field to only one of the three systems. But these systems are interlinked and Ex Libris should handle them as such. Only in very rare cases such fields should only be available in Alma UI and there must be information included in the release notes why exactly something was not added to the API and/or Analytics.