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.

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.

When a user places a request on Primo, the ‘creator’ field in the Analytics requests table shows as ‘System’. When a request is placed by a staff member on Alma, the staff member’s primary ID shows in the creator field.

If a request placed by a user on Primo is subsequently cancelled by a staff member on Alma, the creator field changes from System to the staff member’s primary ID. This means reporting on requests placed on Primo vs. requests placed by staff members on Alma is not accurate and the field is misleading (creator should refer only to creator).

I logged a Salesforce case about this (00801207) and received the following reply:

“The feedback from Development is that this behaviour is by design, for history requests the creator is indeed the cancelling operator so they can know who completed/ cancelled the request. However, we understand and brought it up to them how confusing it is and not informative since the information about how completed requests were created is being lost. PM has also been updated about this issue.

The conclusion is that Alma is currently not designed to provide the functionality you requested, so the next step is to pursue this as an enhancement.”

Hence adding this suggestion.

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.

Library personnel would like to be able to generate a list of titles and related records in Analytics so as to document title changes, facilitate research and scholarly discovery and develop research guides for use within the institution. At this time, the 76X and 78X fields that are used to display various related record types in Primo VE are not currently indexed in Analytics. Rather than use up the limited number of bibliographic local param fields available – which would still not allow for full reporting on related records – our institution proposes that the aforementioned fields and associated data be indexed in Analytics to facilitate full reporting.

Reference – Related Record Types: https://knowledge.exlibrisgroup.com/Primo/ProductDocumentation/020PrimoVE/034GetItConfiguration/ConfiguringDiscoveryInterfaceDisplayLogicforPrimoVE#ConfiguringRelatedRecordServices

Thanks