Currently the limit for email attachments when filling digitization requests is 10MB. We would like institutions to be able to choose their own limit that suits their own institutional email policies (e.g. Otago's attachment limit on their email server is 30MB). Other institutions may wish to have a lower limit so it should be possible to set a limit that is appropriate up to a maximum value that can be supported by the Alma email infrastructure. Our staff frequently bump into the 10MB limit which leads to them cancelling digitization requests in Alma and then manually emailing the attachment to the user which is an inefficient use of technology.

Note that this request is different from "Document Delivery - 10 MB Attachment Limit too small" (https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/35142943-document-delivery-10-mb-attachment-limit-too-sma) which is focused on attachments that are uploaded to Alma and a link sent to the user rather than on email attachments.

We are disappointed with the technical support service provided by Ex Libris. We strongly believe that Ex Libris should provide customers with more effective, prompt and interactive service.

There should be an option to call or chat online in real time with a support person who has a sound understanding of the product in question. This would be in line with all system vendors we have previously dealt with.

We appreciate that there will be some issues that are designated as bugs or enhancements and will require more in depth investigation. However, a direct call/chat option with a properly trained support analyst would quickly and efficiently separate these issues from more general product queries. We are aware that there are many call-logging options used widely by other companies, such as FastCall, TenFold and RingDNA, which can be used to allow customer calls/chats to be registered directly in Salesforce. We believe that Ex Libris should implement this improvement as soon as possible.

Please vote to show your support for this idea and feel free to add comments relating to your experience of this issue.

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.

Currently the only way to use records from NZ in an IZ is to search them in the NZ and perform an action like "order" or "link" on every single record one by one. There are, however, situations where an IZ wants to use a bulk of records. For this purpose we need a possibility to link records in bulk and create inventory for the linked records.

We imagine a linking job that takes as an input a logical or itemized set of records saved from a search in the NZ. The linking job can create physical and electronic (and digital) inventory, similar to current import profiles. The inventory operations for electronic inventory should include an option to specify the desired action if the record and a portfolio exist already in the IZ, out of the following choices:

• Add new portfolio.


• Update portfolio information (the URL).


• Don't do anything.

Use case:
The NZ loads monthly updates from e-book vendors where the IZs have purchased different packages. The workflows for group inventory aren't applicable here because the NZ doesn't possess the necessary information for determining who has rights to which portfolio. OAI is no option because this currently creates duplicate portfolios each time a record gets updated in the NZ. The workarounds currently in place involve sending files back and forth which is error prone and not very efficient.

Currently, there are limited scheduling options for emailing Scheduled Reports (Alma Analytics Object area). Many of our users need reports delivered on the 1st of each month in order to capture the previous month's data. The only option right now somewhat close to that is delivery on the 2nd of each month. This doesn't work for us because it adds the first day's worth of data from the next month to the previous month. I propose adding delivery options for the 1st of each month. Better yet - how about offering a drop-down list where users can choose a certain day of the month for report delivery?

When using the Restore change type under Change item information, the only change made is toggling the "item is in temporary location" back to NO. Any values filled in for temporary library, temporary location, temporary item policy, temporary call number, etc. remain. Restore should clear those fields, or allow operators to keep those fields by unchecking a box that would be checked by default.

If the item has been scanned to have an item policy for special circ rules, that information remains in the record when it is restored, even though that information is not applied. If the item is given another temporary change that doesn't require a special item policy the previous item policy will be applied when it is moved to a temporary location. See attached file for an example, and desired option to clear all temporary info.

This was also suggested in 2017 NERS as Idea 5111: Remove Temporary Item Information during "Restore" Currently, temporary item information is not wiped out when a temporarily moved item is "restored" either via a staff process or expiration of the temporary move date. The info is confusing and can cause issues with Analytics, Manage Sets, and future temporary moves on the item.

See also the idea relating to removing temporary item information: https://ideas.exlibrisgroup.com/forums/308173-alma/suggestions/11012787-remove-temporary-location-not-just-change-indicat

The Description Template Setup Rules list must continually be reordered, since the first (sequentially) rule for which the enum/chron combination meets all criteria is used for the description, even if the enum/chron would more exactly meet a later rule. Regardless, is is also helpful to order the list so that similar rules are grouped together, so reordering would desirable as rules are added or removed.

Currently, the only way to reorder the list is to move a selected rule up or down in the list, ONE PLACE AT A TIME. This is time consuming and inefficient.

Please add the ability to reorder the list by selecting a rule (or group of rules) and dragging it to it's desired new position in the list. Similar to how columns can be reordered in Alma Analytics.

This would greatly improve efficiency in working with the Description Template Setup Rules.

We have already changed our display to 12 hours in the General configuration (General/Other Settings/systemtimeformat is changed to hh:mm:ss a and it operates correctly.) However, there are still many cases when Alma requires us to input a 24 hour time.

For example, when we check out an item and need to change the due time, there is no way to input 12 hours with AM/PM. (Screenshot example: http://screencast.com/t/9B9XC2qbl) We must enter 24 hour time. This has caused an ongoing problem of inputting an incorrect due time (such as "17:00" when we mean to input 7PM), causing stressful interactions and unnecessary waiving of overdue fines.

Can we have an option to change all inputs to 12 hour time with AM/PM the same as there is the option with the display?

When we were a Serials Solutions customer and we used Summon discovery, we also used Direct Linking. What was great about Summon was that it would provide a pane at the top of the screen after linking to full-text content that would provide a way to see all the database targets on the 360 Link page. See attached image.

This same feature would be highly desirable in Primo and is one of the main reasons why we do not currently use Direct Linking. Currently, if the full-text fails to load for the default target, there is no way to see the other full-text options that would have appeared if Direct Linking were not enabled.