User records in Alma come from:
The rest of this page will discuss only those records created for individuals who are NOAA personnel (both Federal employees and contractors) and who have records in the NOAA staff directory. Those records may have originally been created by any of the above methods.
The patron load process tracks a few field for each account in the NOAA staff directory for individual NOAA personnel (including both Federal employees and contractors). For each load, it creates a flat file with the following fields:
For the purposes of the above, individual records migrated from Sirsi are considered "added in a previous patron load".
Records are considered "CHANGED" when one or more of the tracked fields above are changed.
New patron records are created when there is a new record in the staff directory, based on the noaa.gov email address for that patron record. We only load records for NOAA personnel whose accounts are active in the staff directory. Accounts are typically marked as active after the email is activated -- this may be before or after the individual's actual start date.
Because we maintain a running list of the records we have previously loaded, we are able to tell which records are already in Alma and which have changed. Only records with a new active Status, Line Office, Campus Code, or Email Address are updated by the patron load. When we have updates, we synchronize those records with the ones in Alma.
Internal records (those created and managed primarily in Alma) are listed by the patron load process and manually updated so that we do not lose any metadata. External records (those created and managed by the patron load) are automatically updated.
On the first patron load when we detect that a patron is no longer active in the NOAA staff directory, the patron load adds their email ID to a set for newly inactive users.
We import this set into Alma, and then run a Update Users job that will change the following settings for each member in Alma:
These settings make it so that we will be prompted if we try to check something out to the patron, we will have a record of when the account went inactive and why, and the record will contain the information the system needs to validate the Purge User Account job when the time comes.
When a patron who has previously been inactive becomes active again in the staff directory, the patron load outputs a record for them in the update (sync) file, and creates a set that we import into Alma.
External accounts will automatically reactivate, but Internal accounts will not.
Therefore, we check the records to make sure that in Alma:
(These settings are manually updated for Internal users.)
Occasionally, we may find that we have more than one record for a single person. This could happen because:
In these cases, we sometimes have the option to delete one of the accounts (and perhaps update the information in the new account), but this may pose an issue if the account to be deleted has checkouts, notes, or settings in Primo that we want to retain. Instead, a safer option is usually to merge the two accounts in Alma. (We have had Ex Libris enable the Merge Accounts feature for our site.)
Typically, the patron load uses the patron's primary noaa.gov email address to identify the patron in Alma. (This email address must be stored in the Identifiers tab, in the Alternate ID 1 field.)
Occasionally, NOAA will issue a patron a new primary noaa.gov email address (usually corresponding to a name change, although not all name changes result in a new primary email address). Because the new address does not match up to an existing Alternate ID 1 field in Alma, this would ordinarily mean:
To mitigate confusion, the patron load process now tracks Employee ID and checks to see if there exists more than one account (past or present) in the patron record file that has the same Employee ID. In the event that there are multiple accounts with the same Employee ID, it marks the older one(s) as "Superseded" in its internal file, and lists all of the accounts with the same employee ID in a report. We then review and manually merge the old and new accounts.
Not all records in the staff directory have Employee IDs, and we don't have Employee ID information for accounts that were deactivated before late February 2023, so this process may not detect some scenarios where records should be merged.
When a particular staff member has not had an active record in the staff directory for some time, we may choose to delete their record in Alma. (Typically, we choose to deactivate the record in Alma for some time first, as a number of patrons later return to NOAA.)
We currently count how many loads there have been since a patron has been inactive in the patron load files. Our current recommendation is that we start deleting patrons after they have been gone for at least one year. These deletion events may take place several times a year thereafter, but will probably not be on a rolling / weekly basis since they are more time-intensive.
When we delete patrons, we can create a set based on the patron load output logs, to use in a batch job for Purging Users. The latest log will need to be updated to record that the patrons are now deleted. (We also track the number of weeks that patrons have been deleted -- at some point we may wish to remove the oldest ones, but having the list has been useful in tracking down the history of records that have later been re-created.)
