Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

Legend: NOT STARTED IN PROGRESS STALLED DECIDED

Status

DECIDED

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

(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

  1. What are the operational or functional benefits of either option?

  2. What happens to loading Stanford users from UCB?

  3. CSUs have implemented separate databases.

  4. (long term consideration) Who (which UC entity/office) would manage NZ patron database?

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

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

DONE

Fulfillment and ILL FG meet to discuss and have a preliminary vote on decision

  • 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

Fist of 5 vote conducted on moving forward with separate institutional patron record databases instead of creating a single UC patron record database. Unanimous support for separate institutional databases.

DONE

Final decision passed back to ICs and Patron Data Group

DONE

  • No labels