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.

Please elaborate Collection in Analytics. We suggest three ideas for that;

Idea 1)
Collection can be a separate dimension, with the existing/new parameters below;
- Collection ID (existing)
- Collection Name (existing)
- Collection External System
- Collection External ID
- Collection MMS ID (of the collection's BIB itself)
- ★★★ The PIDs of the collection's direct sub-collections (in different rows, not combined with semicolons; should be repeatable so that the created report can show the hierarchical structure of whole collections)
- Collection level (the depth)
- Collection Path (from the collection's top level collection to itself)
- Collection Description
etc.

Idea 2)
If the aforementioned parameters are not capable to show the hierarchy of the collections, nine dimensions for each level of collection can be created as followings;

1. Nine Demensions for each Collection level;
   Dimension 1 : Collection level 1 (top)
   Dimension 2 : Collection level 2
   Dimension 3 : Collection level 3
   ....
   Dimension 9 : Collection level 9

2. Then, each dimension can have the following parameters;
   Collection BIB MMS ID
   Collection PID
   Collection Name
   Collection Description
   Direct super(upper)-collection PID
   Direct sub-collection PID
   Create date
   Modification date
   Creator
   etc.

Idea 3)
Collection can be a new Subject Area.

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.

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

Some of our library staff need to be able to view Analytics dashboards that we have set up for them in Alma but don't need to be able to do anything else in the system, so even a role such as 'Circulated Desk Operator - Limited' gives them options that they don't require. It would be useful to have a role available that allows staff to see the Analytics menu and the Reports section of that menu, but nothing or little else. That role could then be used as the basic role for making Analytics dashboards visible to staff, with only dashboards or reports that have a more restricted audience being made available on the basis of other roles.