Prevent Dedup in UC Library Search by Library Sublocation
Owning group | DISC |
|---|---|
Type of documentation | Practice |
As-of date | Dec 12, 2025 |
Background
Most UC campuses have enabled Primo VE’s duplication detection process in UC Library Search. Deduplication (or dedup), analyzes separate Alma records’ metadata and displays equivalent, matching records as a single record in UC Library Search brief results (more information is available in the ExLibris Understanding the Dedup and FRBR Processes documentation).
While the deduplication process works for the majority of records, unique holdings in special collections can be erroneously deduplicated and displayed with unequivalent holdings in other library locations.
UC campuses can configure Primo VE to suppressing dedup at the library or sublocation level. However, these configurations do not affect any titles linked to the Network Zone. The majority of UC campus records are shared in the Network Zone, which means there is no out-of-the-box configuration possible to suppress select library locations from the deduplication process.
Previously, erroneously deduplicated records were fixed on a case-by-case basis: deduped records were reported to the campus' SILS Discovery representative who then created a ticket with SILS Operations Center to suppress the dedup for those records. This worked but was time consuming and only fixed problems after it already impacted users. Some locations, such as special collections, are particularly prone to incorrectly dedupping with other records.
UC Berkeley and SILS Operations Center worked together to create, and test, an option for bulk suppressing of dedup based on library sublocation and then presented the results to the SILS Discovery Group. In the fall of 2025, the SILS Discovery Group discussed with their campuses to confirm this new practice is a good approach.
Process for Requesting the Suppression of Dedup for a Group of Records
A campus determines there are certain locations or group of records prone to incorrectly dedupping with other records.
Gather the records into an appropriate set(s) and choose to save in network.
The SILS Discovery Represenative should send a ticket to SILS Operation Center (sils-sysops@ucop.edu), with the set name, requesting the NZ run the "Prevent Dedup in Discovery?" job.
SILS Ops Center will run the job and then run the “Recalculate Local Resource Types Job” to force reindexing of the affected records.
On a quarterly basis, campuses can create an updated list of records added since the last dedup and follow the same process as above to request the new records be suppressed.
While typically this would be done quarterly, SILS Ops Center can also run this job on an ad hoc basis if users notify the campus of improperly deduped records.
Additional or Related Documentation
UC: Running the Prevent FRBR and/or Dedup in Discovery Job in the Network Zone
Ex Libris: Understanding the Dedup and FRBR Processes (Primo VE)
Ex Libris: Suppressing Groups of Records from Dedup/FRBR for Primo VE
Ex Libris: Manual Jobs