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.

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.

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

For Usage reports, it's not always clear which publishers are associated with certain Platform names. For SUSHI harvested data, please consider applying Custom Labels to report Analyses and Prompts.

This would be especially useful for American vendor platforms (lots of them have the acronym APS), Oxford platform, Ovid platform, Springer Nature platforms, and SAGE e.g.

aip = American Institution of Physics (AIP)
APS = American Physical Society (APS)
APS Journals = American Phytopathological Society (APS)

Ovid has a multitude of platforms. Would like a custom label applied to these so they display as one platform e.g. OCE, OvidSP, Ovid Insights, Ovid Insights and Ovid Web Server, Alert, Z39.50.

Oxford platforms should be prefixed with [Oxford] as they are difficult to group together when searching by platform.

Springer Nature platforms also need to be treated the same as Oxford e.g. apply custom labels as follow:

[Springer Nature] SpringerLink
[Springer Nature] Nature.com
[Springer Nature] ScientificAmerica
[Springer Nature] BioMed

SAGE also has multiple platforms:

SAGE Journals (this is OK)
sk.sagepub.com = Sage Video and SAGE Research Methods Video
businessresearcher.sagepub.com = SAGE BUsiness Researcher
methods.sagepub.com = SAGE Research Methods, Cases and Datasets, Podcasts
data.sagepub.com = SAGE Stats

Have a complete list of equivalent R4 and R5 platform names if you would like me to provide them to you.

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 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.