Prevent 9xx local fields from being saved to Community Zone (CZ) records
There is a known issue of some sites not adhering to the Community Zone (CZ) Contribution Guidelines and Community Catalog Standards.
An example of this is the addition of local 9xx fields to CZ records.
Ex Libris already uses a normalization routine to validate CZ records which are changed by customers.
However, this routine does not specifically prevent the addition of local 9xx fields, even though the guidelines are clear that only changes which benefit the broader community should be made.
This has been a longstanding issue, but has been fixable in the Primo Back Office to an extent by using normalization rules.
However, Ex Libris has developed the category tree for Primo Database Search by direct API call to Alma, via an Alma job which runs daily for any unsuppressed database record which has the site’s chosen dbcategory field.
The end result is that categories appear in your category tree which belong to other customers, and we have lost autonomy over our own Primo UI.
This would not be an issue if the category tree was developed to instead use the dbcategory PNX field or if the Alma daily job only published IZ records with the dbcategory field.
In lieu of development which supports customers to maintain the integrity of their UI, Ex Libris should stand behind their Community Catalog standards by adding to the validation routine to prevent all 9xx local fields from being saved to CZ records.
Stacey van Groll commented
Note: Ex Libris developed local extensions as their solution to this problem, but they are not mandatory, so individuals may still freely add local fields to shared CZ records.