|
Current situation or problem:
Patron registration data flows to FOLIO from a web-based patron registration form into the Users app to create new User records. These Users will be considered distance patrons and will have no or limited circulation privileges. When these patrons come onsite, their patron group may change, enabling access to circulation privileges, Reading Rooms, and physical card issuing that features a profile picture.
Getting a library account starts with "reader registration". The first step is filling out online form (current form). FOLIO needs to collect the data from pre-registration form and create limited User records for new patrons. Many people (from researchers to tourists) want a physical Library of Congress library card. A card is not required to visit the Library, but it is needed to enter the public reading rooms and is a souvenir.
Library of Congress need this feature but it will likely be useful for other libraries (especially public and national). The solution should be designed in such a way that it would be useful to any library with this need.
Assumption:
LC patrons will fill out web-based patron registration in LOCATE app.
While the feature can be useful for other libraries, initial development will be based on Locate <> FOLIO integration for getting patron registration data.
Use Case(s) in scope:
This feature is a part of
UXPROD-3988
Draft
and includes:
- Create FOLIO patron (User) records based on web-based patron registration form filled out by the patron in the LOCATE app.
- Save and display user pre-registration fields in FOLIO user record. Additional data elements that need to be collected and that aren't in Users should be handled as custom fields.
- Indicating via note if User is banned

- Indicating that User is minor (under age 18)

Out of scope:
- Create a physical library card (Collect photo, issue card, reprint lost library cards)
- View action log (create card, modify reader data, add photo)
- Library staff who work with reader registration records should not have access to all user records. - Congressional User records should only be accessible to a subset of the staff who access User records (
UXPROD-4119
In Progress
).
- Delete old reader registrations. - LoC will not delete old/inactive User records.
- Assign a patron barcode
- Reader lookup log. View history of every time an account was looked up.
- Renewing library cards
- Lost library cards
- Consolidate multiples records
- Specific registration for users under 18:
- Staffer already has User account but wants to get a library card with their parents
- This suggests that creating a user record from a reader registration record should be optional
- In this case, perhaps the user record is manually linked to the reader registration record?
Proposed solution/stories:
- Use Edge-API for getting pre-registration data from LOCATE. Extend Edge-API with the ability to create user records. If pre-registration currently is not ready, consider data simulation of getting pre-registrations.
- These Users will be considered distance patrons and will have no or limited circulation privileges. When these patrons come onsite, their patron group may change, enabling access to circulation privileges. The patron interface could potentially be customized to provide the experience LC wants for their patrons:
- To require that certain fields be populated (LC requires name, email, phone and address to be populated while FOLIO backend only requires name and email (plus patron group)). See attachment.
- To have basic validation of fields that are prone to error such as email (FOLIO itself doesn't do this kind of validation).
- Different institutions may want to collect different data elements in pre-registration. To handle this, some configurability needed to be implemented in FOLIO.
- Additional data elements that need to be collected and that aren't in Users should be handled as custom fields (see attachment). For example, the pre-registration form includes an acknowledgement plus some opt-ins for marketing emails, user type specific fields. Custom fields should work for this.
- Consider mecahnism for creation of custom fields that are required by LoC as a part of tenant configuration.
- Newly created user records should have default values
:
- Patron group: configuration setting?
- Status: Active
- User type: Patron?
- Expiration date: configuration setting?
- Permissions: ?
Links to additional info:
Questions:
- [LoC] Do we need to auto-generate barcodes? Should barcodes be generated for user pre-registration records or can be added after onsite review by Reader Registration Staff?
- This will be dependent on/likely "live" in a Patron Registration solution that lives outside FOLIO (maybe inside Locate?). I assume that barcodes will be generated wherever the Patron initially submits their personal information, and then passed to FOLIO. Recent notes indicate that the patron's barcode would serve as the userID to sign in to Locate. If so, the barcode would be needed for both remote and onsite users.
- Default values for pre-registration records: patron group, status, user type, Expiration date (setting or patron group), permissions
- [LoC] Do we need to collect signatures?
- LoC do not need to collect signatures.
- “System must have the ability to issue a temporary card for patrons who do not show appropriate ID. Temporary cards must display temporary status and have an expiration date of 7 days.” - should it be a unique patron group? Will it be assigned by Reader Registration Staff or should be set by default?
- “Library cards issued to minors must have a noticeable attribute on the physical card.” – should this be a visual distinction or flag in the Patron record?
- [LoC] Banned user records. - Should this be applicable for access to reading room or for User record? If it's for a user record, can it be indicated just with “inactive” user status? Do we need to save a reason for deactivation?
- We'd like to work with the IC's on options to accomplish this via Patron blocks and notes. The need is to indicate that someone is banned from the physical premises in addition to blocked from any circulation actions. There needs to be some indication that a staff member should not simply re-activate an Inactive patron that has been banned, but again that might be doable in a note?
- “Search user record by multiple criteria (search, filter, view results, sort)" – Do we need to have additional search criteria beyond the existing ones in FOLIO?
- [LoC] “Consolidate multiples records” – does this require any development?
- We would like the patron registration solution to validate (the text string of) and verify (make the user click a link sent to) the patron email addresses. If that is the case, the need to consolidate (or de-duplicate) is not critical. Our current system does not do this, so a patron can submit their data many times and has led to many duplicates.
|