Single UC-wide patron record database or separate institutional patron databases? (PDCG)

Legend: NOT STARTED IN PROGRESS STALLED DECIDED

Status	IN PROGRESS
Description	Decide if the SILS project will adopt a single UC-wide patron database or allow for each campus to create and manage their own separate institutional patron database. (Patron Data Cleanup Group)
Decision	Each campus will create and manage their own separate institutional patron database
Owning group	Fulfillment & ILL
Approver
Stakeholders	R/A = Fulfillment & ILL C = Patron Data, Public Service I = ICs Patron Data group is waiting for this info for next steps.
Decision-making process	Fulfillment & ILL will make recommendation and pass to ICs (info) and PDCG (next steps).
Priority	Choose one: Mandatory before Go-live Useful before Go-live Within one year after go-live Post-live (1-5 years)
Due date	21 May 2020 (orig May15th requested - PDGC meets Mondays

Recommendation

The Fulfillment and ILL FG recommend creating and managing separate institutional patron databases. Alma fulfillment networks can be configured by sharing specific patron information fields, determined by the network members, and are not dependent on the creation of single unified patron databases. The FG was unanimous in its preference for a decentralized model, with local cleanup decisions.

Background

The work of the Patron Data Cleanup group, as well as others potentially, will be highly impacted by this decision. A single unified patron database will demand a higher level of harmonization decisions being made as it pertains to user fields in Alma and the data being migrated from the current integrated library systems. A decentralized model allows each campus to essentially focus more on “cleaning their own house” and make decisions about “their patron data” locally within the scope of what can and cannot be technically migrated.

Dependencies

The Should expired patron records be migrated to Alma? (PDCG) decision depends on this decision.

If the shared patron records will exist in the NZ, then these 3rd party integrations will need to be listed for the NZ 3rd party integration form due May 29th.

technical consideration: can the NZ (if that is where the shared patron records will be) have ten SIS integrations? (posed to ExL on May 8 )if not, how will the shared patron records be ingested into Alma?

Questions to consider

What are the operational or functional benefits of either option?
What happens to loading Stanford users from UCB?
CSUs have implemented separate databases.
(long term consideration) Who (which UC entity/office) would manage NZ patron database?
ICs: After some thinking on this, it seems like having multiple databases would be significantly LESS work for the same “bang” - we tentatively recommend this course, but defer to the experts.
Will there need to be work done to put forth recommendations related to patron identifiers? Who owns this work?

Action Log

Action/Point Person	Expected Completion Date	Notes	Status
Send out email to review decision information Elizabeth Rodriguez (Unlicensed)	11 May 2020		DONE
Fulfillment and ILL FG meet to discuss and have a preliminary vote on decision	14 May 2020	Initial response from the group is unanimous support for a decentralized model. One thing to consider is that if we decide on separate institutional patron databases, it could be that this group puts forth additional recommendations in the future related to patron identifiers. The Patron Data Group may already be working on this, or we may need to make recommendations to them.	DONE
Final review and decision	21 May 2020
Final decision passed back to ICs and Patron Data Group