Users App: Department Field

Cornell: a small group evaluated the options for Cornell with regard to Patron Codes. It appears that the combination of the Department field and Custom fields will provide the solution that Cornell needs. Testing of custom fields and reporting from them can begin with GoldenRod. Testing of Department fields and reporting from them can begin with Honeysuckle. The Cornell Patron Feed will be modified to accommodate the Patron Code reporting needs identified in REP-221.

Pending testing, it appears that Cornell does not need to implement Statistical Codes in the Users application.

Data feed is the most common case, but far from the only case.

• Some smaller institutions might not include this info in their feeds at all, meaning manual input may be only way to capture it.

• It's fairly common these days to have faculty who have interdisciplinary appointments and grad students working on interdisciplinary issues. I've been at 2 institutions where identity management couldn't/wouldn't control which department is in the feed in these situations. Libraries will need to be able to alter field and lock it in these cases.

Happy to provide specific examples if it'll help.

Hi Khalilah, suggest taking that proposal to RA. I think you will find people don’t want it to be read only.

and , I think this is my struggle with Departments. Same feed supports both. So if we do separate settings, same feed supports the same thing. Also I guess the other question is this - Does Users need a Departments CRUD? Is it enough to have the data feed populate Department value(s) in a User Record. So I propose - User record's Department field is read-only and can only be updated via data feed IF that is the common use case.

1. Correct.
2. Identity matching, reporting, and facilitating services. For example, if I know that someone’s department is history, which is on our east campus, I know the library they are probably most comfortable with is the library on that campus and can refer accordingly.
3. Yes. Using Duke as an example: If you are an employee (faculty or staff), you have an associated org key in your identity record that maps to your hiring unit / department, which could be academic or administrative. If you are a student, your identity record will have an associated key that maps to your degree program. If you are a student and staff at the same time you would have both.