When updating one user manually, we get a notice where we can confirm that some fields (amongst others: campus, rs libraries and user group) are not to be overwritten by the next user synchronization.

When updating users in a set running the Update/Notify Users job in Alma, the same choice of prevention is not presented. Hence leaving some fields to be changed back in the next synchronization.

We experienced this running a job changing campus, RS library and user group on a set of users. The first two fields did not change back in the synchronization. The latter did.

Would it be possible to have the same choice of prevention running a job on a set as we do when updating one and one user?

This time we had to change manually nearly 500 users. We would very much like to spend our time and resources on more fruitful work in Alma and in the library.

Best,
Ann-Louise Skjager
Special librarian
Oslo Metropolitan University

Because all norm rules can be edited by all staff with cataloger roles, there is great room for erroneous changes for rules that are applied to batch jobs. For example, the norm rule that is applied to records being brought in from Z39.50 targets can be edited by any staff member. A single error in the rule can break the z39.50 import process for all staff until the source of the error is identified. Likewise, if we have a rule applied to import profiles and a staff member inadvertently changes it and we load 50,000 records, that could cause huge data corruption. There needs to be a way to secure a norm rule to administrators such that normal staff with cataloger roles cannot change them.

When setting recall period on a fulfillment loan to "No recall due date", the original due date is kept, while renewal of the recalled loan is blocked.

For some reason, a different logic is applied to lending requests. Setting "No recall due date" as the recall period policy for lending requests, results in the due date being set to the date of the recall. The result is unpredictability for the borrower.

We propose that that these two very similar workflows are better alligned and that setting "no recall period" for recall should result in no change to the due date on a recalled lending request.

Audun Skorstad
Unit – The Norwegian Directorate for ICT and Joint Services in Higher Education and Research

The current implementation of exclude process types from publishing has the side-effect, that a holdings record gets automatically suppressed as well if it only contains items which get suppressed based on the exclude from process types configuration.
E.g. if you have process type=acquisition, material type=issue, exclude=true all holdings which happen to only have items with material type issue in process type acquisition are suppressed no matter what. This is bad in itself, since it precludes the possibility of offering additional information to our users via the 866 field.
What makes things worse is that the bib record gets suppressed as well if the automatically suppressed holdings record happens to be the only one for the title and if you have the flag suppress bib with suppressed holdings set to true.
We understand that the current behaviour may be desirable to some, for us it necessitates weird workarounds including dummy holdings / dummy items. So we would urge ExLibris to consider making the suppression of holdings which virtually end up with no items an optional thing.
After all for regular holdings with no items we have a choice whether we want these suppressed or not. For exclude process types from publishing ExLibris made some assumption regarding the correct behaviour which for us simply don't apply.

Oliver Lehner
TU Wien library

My libraries circulate various pieces of equipment from microphones, to musical instruments, to 3D printers, to lockers, and the current physical material type table does not suffice without adding a slew of item policies or location codes, which is messy and makes the resulting analytics more painful than it should be.

Ex Libris support states that "The [physical material type] codes cannot be changed, because Development needs them for statistics across libraries." However individual libraries will have items that they need to distinguish between either for fulfillment rule purposes or our own statistics.

I would like there to be about 15 generic material types added to this table that will allow libraries a bit of flexibility in dealing with this category. Similar to how Primo has blank PNX fields that can be used to create additional facets, etc. that best fit the needs of the library and its users.

The new short_loan_courtesy_reminder & short_loan_overdue_reminder cannot be configured for multiple locations. For institutions with several hourly loan locations (for example Boston College maintains 2 and 3 hour loan periods for Course Reserves and a 4 hour loan period for some technology items) this dictates that the reminder notice has to be set based on the location with the shortest loan period. The overdue notice must be timed to make sense for for the longest loan period.

In our test configuration we used the following time parameters:

​short_loan_courtesy_reminder - 105 minutes
short_loan_overdue_reminder - 241 minutes

However, this creates a situation whereby patrons borrowing from some locations will have already incurred an overdue charge before the overdue notice is sent.

In order for this functionality to provide the service is designed for, it must be robust enough to support different loan periods.

https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/030Fulfillment/080Configuring_Fulfillment/110General#Configuring_Fulfillment_Jobs

When using Lender Due date for RS items (Fulfillment > General > Other Settings > ignore_lender_due_date = false) the date for Pick up from shelf is the same as the Due date. This is, according to ExLibris, working as intended, but we have a few issues with the workflow.

This makes the workflow more manual and difficult than needed, given that we have to manually check RS items that is not getting picked up by patron within a couple of weeks. Having the RS items on Hold shelf for up to 4-6 weeks is poor use of time - for the patrons, the book and the library.

If we could set a Hold shelf expiry date for RS items that is shorter than Due date, it would make it easier for the circulation desk personal to remind patrons that they have a book waiting. This will give the book more time at use with the patron, and less on the hold shelf. It will shorten the waiting time for other patrons, as the book will be returned earlier to the owning library if it is no longer needed by the patron.

The best would be if this process could be automated, e.g. by TOU policy. (Much like the Hold Shelf Period policy that exist for TOU type Requests.)
If it’s not possible to populate a Hold expiry date automatically, a data field in the receiving RS items pop-ups would be helpful. (Pictures added.)

University of South Australia Library would be interested in accessing various error reports for the jobs that we run at the time when we run the jobs.
We are aware we can check Import errors as per "Resolving Import Issues" but for other type of jobs we cannot check error reports.
As an example, running a filtering job on a set provides us with a report including a brief information on the number of records that "failed" as in this message:
"Of the 67201 records processed, 4 records failed. For more information view the report details (or contact Support using the process ID)." I attached a file with full details of this report.
We would very much appreciate having access the all error reports for the jobs that we run at the time when we run them, without having to create an incident case asking Support for error reports each time when we have problem records.
We believe that allowing us to check the problem records before creating an incident report would save time for everyone, as we could fix certain problems without creating incidents.
Thank you for your consideration,
Daniela Nastasie

We would like to be able to copy multiple lines from MARC records and paste them into the metadata editor so that multiple MARC fields are pasted into the record in one action. This would help us enormously with our workflow of importing MARC authority records from LibrariesAustralia into Alma.

For us, this is necessary because the LibrariesAustralia headings are not in the community zone and are unlikely to ever be included there and Alma does not allow for Z39.50 import of authority headings.

We have this functionality of copying and pasting multiple fields in the LibrariesAustralia Cataloguing Client and other library systems allow it. At the moment we need to paste each line one by one into Alma and it is slow and repetitive. This process is a step backward from previous functionality.

There is a crucial step missing in the Automatic Generation of the Summary Holdings Statement Based on Items process. The process is documented here:
https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/040Resource_Management/040Metadata_Management/020Navigating_the_MD_Editor_Page?uxp=true#Automatic_Generation_of_the_Summary_Holdings_Statement_Based_on_Items

When items which are linked to the Holdings record are withdrawn, there is no process to update the Holdings record 863/864/865 fields to create an updated 866/867/868 field. When items are withdrawn, the user has to manually edit the Holdings records.

Since the creation of the 863/864/865 field is now automated based on received items being linked to the holdings record, there is a need for the 863/864/865 to be automatically re-created when the linked items are withdrawn.