User record fields.xlsx

	A	B	C	D	E	F
1	Property Name	Pilot	Priority	Notes

2	username		Cornell: 0, MO State: 0; Duke: 0; Leipzig: 0; GBV: 0
3	id
4	externalSystemId		Cornell: 3, MO State: 3; Duke 3; GBV: 2			Proposed priority:
5	barcode	Yes	Cornell: 1, MO State: 1; Duke 1; Leipzig: 0-3 (see notes); GBV: 1	Duke: Would you search by individual barcodes, would you upload a list of barcodes to get the search results, or would you search by wildcard? The latter two (upload a list or search by wildcard) are the only two where it would seem like barcode could be useful. If those would be available, we would rate this as a 1 or 0. If it was just individual barcodes, we would rate this as a 3. Leipzig: Agree with Duke. In our library the barcode is the unique HRID every user gets. We need to upload a list/file of single barcodes, searching single barcodes would make no sense for us as well.		0 - Must have
6	active		Cornell: 2, MO State: 2, Duke 1; Leipzig: 2; GBV: 1	Status in UI		1 - Important
7	type			it seems to be always set to patron		2 - Can wait
8	patronGroup	Yes	Cornell: 0, MO State: 0; Duke 0; Leipzig: 0; GBV: 0	UUID		3 - Not important
9	permissions	Yes	Cornell: 2, MO State: 2; Duke 0; Leipzig: 1; GBV: 1	call to /permissions endpoint Duke: if we can do the search here to pull up user records that all have the same permission or permission set, this would be extremely valuable
10	id					.
11	userId
12	permissions
13	metadata
14	departments		MO State: 1; Duke: 1; Leipzig: 2; GBV: 1	UUID
15	personal
16	lastName		Cornell: 3, MO State: 2; Duke: 3; Leipzig: 3; GBV: 3	Please provide example of use cases
17	firstName		Cornell: 3, MO State: 2; Duke: 3; Leipzig: 3; GBV: 3	Please provide example of use cases
18	middleName		Cornell: 3, MO State: 3, Duke: 3; Leipzig: 3; GBV: 3
19	preferredFirstName		Cornell: 3, MO State: 3, Duke: 2; Leipzig: 3; GBV: 3	Duke: potentially useful if you can use this to see if the field is populated
20	email	Yes	Cornell: 3, MO State: 1, Duke: 1; Leipzig: 3; GBV: 0	Duke: For the purpose of finding records to do bulk edits on, we would only really find this useful if you could do a search with wildcards (e.g., "show me all the patron records with an email address ending in ncsu.edu") - 'contains' as a search parameter was requested by UM SIG
21	phone		Cornell: 3, MO State: 3; Duke: 3; Leipzig: 3; GBV: 3
22	mobilePhone		Cornell: 3, MO State: 3; Duke: 3; Leipzig: 3; GBV: 3
23	dateOfBirth		Cornell: 3, MO State: 3; Duke: 3; Leipzig: 3; GBV: 3
24	addresses
25	id
26	countryId		Cornell: 3, MO State: 2; Duke: 1; Leipzig: 3; GBV: 3
27	addressLine1		Cornell: 3, MO State: 2; Duke: 3; Leipzig: 3; GBV: 3
28	addressLine2		Cornell: 3, MO State: 2; Duke: 3; Leipzig: 3; GBV: 3
29	city		Cornell: 3, MO State: 1; Duke: 3; Leipzig: 3; GBV: 3	Please provide example of use cases
30	region		Cornell: 3, MO State: 1; Duke 3; Leipzig: 3; GBV: 3	Please provide example of use cases
31	postalCode		Cornell: 3, MO State: 1; Duke: 3; Leipzig: 3; GBV: 3	Please provide example of use cases
32	addressTypeId		Cornell: 3, MO State: 1; Duke: 3; Leipzig: 3; GBV: 3	Please provide example of use cases
33	primaryAddress		Cornell: 3, MO State: 2; Duke 3; Leipzig: 3; GBV: 3	Please provide example of use cases
34	preferredContactTypeId		Cornell: 3, MO State: 3; Duke: 3; Leipzig: 3; GBV: 3
35	enrollmentDate		Cornell: 3, MO State: 3; Duke: 1; Leipzig: 3; GBV: 2	Duke: This field could be a proxy for class year in some scenarios, so it would be a really nice option to have.	Please provide example of use cases
36	expirationDate	Yes	Cornell: 3, MO State: 2; Duke: 0; Leipzig: 2; GBV: 1	Duke: You absolutely need to be able to do a bulk edit for patrons based on whether they have expired or not.
37	createdDate		Cornell: 2, MO State: 3; Duke: 1; Leipzig: 3; GBV: 3	Duke: This field (or the metadata equivalent below) can be a proxy for account creation workflows and can assist in being able to identify accounts of a certain type, so it would be nice to have.
38	updatedDate		Cornell: 2, MO State: 3: Duke: 1; Leipzig: 3; GBV: 3	Duke: This field (or the metadata equivalent below) can be a proxy for account creation/management workflows and can assist in being able to identify accounts of a certain type, so it would be nice to have.
39	proxiefor			call to /proxiesfor endpoint
40	userId		Cornell: 2, MO State: 2; Leipzig: 3; Duke 2; GBV: 3
41	proxieUserId		Cornell: 2, MO State: 2; Leipzig: 3; Duke 2; GBV: 3
42	id
43	requestForSponsor
44	notificationsTo
45	status
46	expirationDate		Duke 1
47	metadata
48	metadata
49	createdDate		Duke: 0	Duke: This field can be a proxy for account creation workflows and can assist in being able to identify accounts of a certain type, so it would be nice to have.
50	createdByUserId		Duke: 0	Duke: We'd want this in order to be able to do bulk edit/review of accounts created by staff, especially new staff - this can be useful for troubleshooting. Europe: obviously not allowed per GDPR
51	updatedDate		Duke: 0	Duke: This field can be a proxy for account creation/management workflows and can assist in being able to identify accounts of a certain type, so it would be nice to have.
52	updatedByUserId		Duke: 0	Duke: We'd want this in order to be able to do bulk edit/review of accounts created by staff, especially new staff - this can be useful for troubleshooting. Europe: obviously not allowed per GDPR
53	tags		Leipzig: 1; GBV: 1
54	customFields
55	id
56	name		Cornell: 1; Duke: 0; MO State: 0; Leipzig: 0; GBV: 0	Duke: We would want to be able to search by custom field value, not just the label - e.g. ("Show me all the patron field records where the "Patron Type" custom field has a value of "Summer Programs".) GBV: change all users with custom field "faculty" and content "Library Science" Leipzig & GBV: +1 Duke
57	refId
58	type		Cornell: 2; Duke 2
59	entityType
60	visible
61	required
62	order
63	helpText
64	checkboxField
65	selectField
66	textField
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100