Page Comparison

...

Create a staging table with fields:
1. First name
2. Last name
3. Email
4. Tier: 1,2
5. Etc. fields from Tier 2 registration form
Modify (edge) POST API to store data in the staging table and accept:
1. Tier 1 data: only store First/Last name and email address
2. Tier 2 data: store full data
Create GET API for staging table to search/filter data by email/first name/last name
Create UI for staging table to search/filter data by email/first name/last name
Create PUT API to link patron record with staging record
1. Create a patron record if not present in user table and link it
2. Link existing patron record with staging record
Create UI dialog to:
1. Link a staging record with a patron record
2. Show a list of patron records to choose from
3. Go to user app with the selected patron record

Comparison with patron-group based solution

	Attribute	Registration with non-circulating patron group	Registration with staging table
1	Security	Unfinished registration records can lead to potential security issues	Possibility to create big amount of registration in users table is isolated to staging table only
2	Performance	Unfinished registration records can lead to performance degradation as `users` table is already used for storing patron and users information	Patron records in FOLIO `users` only appear after id confirmation onsite
3	Analytics	Information on Tier 1 registration is available in Locate. And only information on Tier 2 registration will be in FOLIO	Information on Tier1 and Tier2 registration is available in FOLIO
4	Estimation	Medium: mostly reuses existing FOLIO implementations and mechanisms	Extra Large: Requires additional UI and implementation of staging table

Do we need to keep invalid tier 2 data in the staging table?
How do we update the records? How do we handle renewal? - no update
How do we update the staging record if we update email updates in the users table?