Processes to Shift / Stop: Patron Records Discussion
Definition:
• Grab information from a university system and load into out system (bulk)
• Manual adds
• Overlays (updates)
Authorization
• Role/Status (student, faculty, alums, etc)
• Rules for specific people/roles
• Associated users that might never appear in the university system
Why did we red dot?
• The word create my have been misleading
• Problem is keeping data in two places
• Library system can tap in rather than copy
Running an extra system for community members, etc.
• Problem for most LDAP systems to look in two containers. Eliminates
duplication but confusing for patrons to have different logins.
• Shibboleth (trusted peer I/A/A)
Fines
• Could be a fine table with a key that links out to master system (rather
than a patron table) for patron information
Issues if eliminated:
• Service and reliability (are the external system(s) consistently reliable?)
• Adds another level of dependency
• Political issues
• Security – we (library staff) won’t have as much access to the information
(could be addressed as a “system to system access”)
• Library data (ex. addresses) can be more up to date (can we update?)
• Will a master system be willing to hold our [library-specific] information (do
we need to keep that information?) – sub-table like fines?
OLE Project BPM Workshop – Utah – January 14-15, 2009