We mapped all five local params soon after migration. We chose them very carefully because there were so few and they're fixed. This involved discussion with multiple stakeholders, planning, meetings. We only recently gained the ability to add five more. I don't feel it's appropriate to say this functionality is not needed because no one has yet completed this process for the next five. These fields are so precious and difficult to change that we feel we need to save them in case of unforeseen circumstances. Coming from III, the lack of this functionality is troubling to say the least.

Yoel, is it possible that only the fields, not the subfields, could be represented as I described below in a filter?

Could you elaborate on your statement: Analytics is not designed or purposed for such a feature. We have used other reporting systems that were not designed for such a thing, but they have been adapted to include it.

Thanks

Hi Yoel, I understand the current design, but I wanted to share one perspective of a site currently using only 2 of our 'local' bibliographic fields. I feel it is a bit misleading to use such a broad statement of only one site using all 10 fields as justification for disregarding the community feedback. Up to just a few weeks ago in the January 2019 release, we only had a limit of 5 fields, and they had to include a 9. It was only in the January release that the limit raised to 10 and we could finally choose truly non-local fields without a 9 in any position. We only mapped 1 during our implementation in 2016 because 5 was so few, we wanted to choose well given we had no expectation of more, it was also so limiting with the 9 position requirement, and we did not feel it reasonable to do even more work to move data from a correct non-local to local field. We have now mapped another field, and we are contemplating more, but again have the same thought of "We only have 10 and we have already used 2!" There is also an administrative burden of submitting cases, waiting for indexing, testing, and then documenting for staff outside of Oracle what each of the Local Params labels actually means. The argument from our side is that is would be truly an awesome and powerful tool if we had all of our data available to us for examination and analysis out of the box. This is particularly true when we also are limited to Indication Rules in Alma for many fields as well, rather than just being able to enter any MARC field and subfield as a search index, add free text search terms within these chosen fields, and immediately find our data. We moved from an LMS that allowed us to do this, which adds to the frustration greatly that a new generation system with an active and dynamic development schedule still does not provide this seemingly basic functionality. It sometimes feels like our data is tantalisingly close but also locked away behind time consuming administrative walls.

Analytics will not include all MARC fields and subfields.
Analytics is not designed or purposed for such a feature.
Currently each institution can add 10 non control fields of their choice (bibliographic and holding and does not need to include a "9") to what already exists.
We see that all ten additional fields are not used by any institution except one, thus see little justification for adding more fields.
With that said, if a group of users can come with very specific field subfield combinations and say "this is what a lot oi institutions need and here is why" then it will be considered.
But, again, Analytics will not include all MARC fields and sub-fields.

It seems that it would be relatively simple: have the tags in the filter. We can use Excel to do more filtering.

Thinking the same.. I vote for this idea because we need this functionality in Analytics.

We need the ability to report on elements of the bib and holdings Leader for records modified by particular staff on particular dates in order to check their work on bibliographic maintenance projects. The ability to create a set in Alma IS NOT the same, does not allow us to find the information we need, and does not meet our requirements.