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?

It would be exceptionally helpful to be able to run Analytics reports on all areas of Alma Configuration.

It should be possible both for each individual library to run the reports on their own behalf, AND for libraries belong to a consortium, possible for consortial staff to run the reports across all institution zones simultaneously for comparison between member IZs.

Use cases:
1) Reviewing a spreadsheet containing all of the settings in a configuration area makes settings review easier, and reduces errors. Needing to click between screens and take screenshot to compare settings is cumbersome, and leads to mistakes or unintended differences between settings. It is also easier to review many settings in comparison to each other (example, Fulfillment TOU and Rules), and it is easier to discuss the settings with colleagues through a report format.

2) Since Alma does not maintain an internal change log to configuration changes for most settings, it is possible that library staff may accidentally change configuration and be unable to recover what the settings were prior to the change. The ability to run reports provides libraries with the opportunity to snapshot their settings, in case edits occur that need to be reverted.

3) When libraries are in a consortium, that consortium may have consortial configuration settings/policies that each library should follow. Without the ability to run reports on Configuration settings, consortial staff must log in to each member's institution zones individually, and review each setting manually. This is inefficient, leads to the potential for error, and can impact the patron's experiences. This also prevents consortial staff from being able to provide reports that allow member institutions to compare their settings to the settings of other member institutions for baselining.

We have been using Voyager since 2002, and have had the ability to report on Voyager System Administration settings. I have found those reports invaluable in my time working at the consortium, and would appreciate the same access in Alma/Primo VE configuration.

Currently it's possible to create a set directly from Analytics, but the end result is an itemised set. This functionality is great for skipping a few steps in exporting a file from Analytics, but fails to take advantage of the dynamic nature of daily Analytics updates. To do that, we need the option to create a Logical set which is tied to an Analytics report.
Use case: We have three Analytics reports for three Publishing Profiles for specific local License Terms, which are sent to an external Resource Sharing provider (RapidILL). We cannot create these sets in Alma due to very limited ties between License records and terms and the required electronic inventory information. At the moment, we periodically manually update from File, and now from Analytics, with refreshed itemised Publishing Profile Sets, but if we could keep the set as Logical from Analytics we could completely automate the process.

Currently to identify self check stats for loans and returns in Analytics you either need to do one of the following:

1. Create separate Circulation Desks for self checks


2. If the operator Primary Identifier field is "None" assume the loan or return was a self check one

Neither of these workarounds work if you choose to delete Library staff records from Alma and not retain full statistics in Analytics or if the Circulation Desks are deleted (which can happen if a Library is closed)

It would be preferable to have a separate field in Analytics that indicates whether a loan or return was a self check one - that way the stats can't be impacted by the deletion of staff or Circulation Desks

Since the recently released August version, Analytics does not longer show the auto-renewal date due to a mentioned performance improvement on the nightly job. Please consider rolling back this change as it actually makes it impossible to get how many auto-renewals were made on a certain day in the past, since the only date we currently have is the Last Renewal Date which is updated every time the job runs. We virtually lost our auto-renewals log integrity.

I know we still have this Last Renewal Date, the amount of auto-renewals and the Loan Date, and we could easily calculate the auto-renewals specific dates doing some basic maths but this approach is not reliable because a loan could be manually renewed and its due date could be manually changed.

Consider rolling this back, because we ended up with no option but to disable auto-renewals in order to keep this renewals record for future queries, and these manual renewals will be processed individually on Analytics so it makes no sense to the desired improvement.

Problem: We are looking for a way to run a cost usage report by fund that includes titles with the PO Line Type ‘Name of Electronic Collection - Subscription.’

Description: Our library evaluates cost per use of all serials by fund. We have been able to run a cost per use report by fund for our print and electronic journals. We run into a roadblock, however, when we try to generate a report on the cost/use of a database by fund.

The E-Inventory Cost Usage report includes all titles with the PO Line Type Name of ‘Electronic Journal - Subscription.’ However, it does not include titles with the PO Line Type Name of ‘Electronic Collection – Subscription’, which is the line type name for all of our databases. Without a cost per use report by fund that includes databases, we have to spend a lot of time creating a report by hand using information that is stored within Alma, but not retrievable as a report.