Users Administration
- Adding a new employee to the sandbox
- Troubleshooting when a patron is not loaded into Alma as expected or being updated by the patron loader as expected
- Special use cases for user access
- Updating patron loader with new academic program codes
- Updating Patron Loader with new employee departments
- Understanding Alma patron identifiers
- SCL Users that migrated from Aleph to Alma
- DRAFT SOP for annual User Role audit
- Patron access to Electronic Resources
Links
Gitlab project: https://gitlab.oit.duke.edu/alma-integrations/patron-loader
Integration setup for weekly full run: https://duke.atlassian.net/wiki/spaces/LIDS/pages/394100843
Integration setup for daily incremental run: https://duke.atlassian.net/wiki/spaces/LIDS/pages/394100987
Ex Libris documentation on their canned support accounts that cannot be removed: https://knowledge.exlibrisgroup.com/Alma/Product_Documentation/010Alma_Online_Help_(English)/050Administration/030User_Management/99Ex_Libris_User_Accounts
Answers to other questions
A student reported that they have officially changed their name with the Registrar (Biographical and Demographic Changes | Office of the University Registrar ) but that change is not reflected in the patron file we are receiving. What could be going on?
Ask if the student has employment with Duke (or see if they have a “staff” status in directory.duke.edu in addition to their student status.) If so, they probably have not changed their name with HR. Once they’ve changed their legal name with HR, you should see it start to appear in the patron feed.
The patron loader rejected a user with a message like “Identifier of type XX and value blahblahblah is already taken AcrossInstitut...” What does that mean?
This message appears if the patron loader is trying to sync a user with an ID where the ID value already exists somewhere in Alma. Scenarios where this has come up included
A patron created manually before being loaded and the manual patron is internal;
A patron in the “special collections” group that migrated from Alma with a unique ID, and has now returned to Duke with their same unique ID;
A patron updated by staff where they added a brand new mobile ID number but choose the wrong ID type
The solution to any of these could vary, but basically you need to get it to the point where the ID value coming in from the patron loader is either new to Alma and completely unique, or matching an existing account identifier in the way Alma expects it to match. This could mean removing an ID from an account already in Alma or changing the identifier type, depending.
A student recently graduated from DKU and started a graduate program at Duke that fall. They are not loading in the patron loader - what could be going on?
DKU continues to show recent alums as students; in the identity management feed, they have a status dudkuprimaryaffiliation = STUDENT.
Because they then also have DKUinDurham = 0, the patron loader thinks they are active students in Kunshan and does not add them to the zip file for import.
The fix for this is that OIT has to remove the dkuprimaryaffiliation (see example in SN - TASK8607798).
The student will lose access to any DKU resources that they were still accessing from DKU.