Skip to Main Content

Alma / Primo Migration & Training Guide

Patron Load - Record Management

Contents

Where do the patron records come from?


User records in Alma come from:

  • Records migrated from Sirsi
  • Records manually created by library staff (e.g., Interlibrary Loan records)
  • Records created by the Patron Load process, based on records in the NOAA staff directory
    • These are typically External Records and are created by "SIS" (for records created in 2022) or "PATRON_LOAD" (since 2023)

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.

Monitoring the patron record lifecycle


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:

  • the status of the record in the patron load (see below)
  • Line Office
  • Campus Code
  • Primary email address
  • Alternate email addresses
  • Employee ID
  • Last output date (new or changed)

Patron Load Statuses

New
Added in the most recent patron load
Current no change
Added in a previous patron load and not changed since then
Current - CHANGED
Added in a previous patron load; Updated in the most recent patron load
Inactive_##
Added in a previous patron load, but not active in the most recent patron load. Marked as Inactive in Alma.
The numbers at the end are a counter for the number of patron loads since the record became inactive.
Reloaded
Previously inactive, but reactivated in the most recent patron load
Superseded
Added in a previous patron load, but a new email has been detected with the same employee ID (indicating a name/email change). Merged into the record with the new email.
Deleted_##
Patron account was deleted after extended inactivity. The numbers at the end are a counter for the number of patron loads since the record was deleted.

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.

Creating records with the Patron Load


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.

Updating records with the Patron Load


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.

 

Deactivating user records in Alma

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:

  • set Status to Inactive
  • set Expiration Date to the current date (if Expiration Date is empty)
  • set Purge Date to the current date (always)
  • add the EMAIL_INACTIVE user block (which reads "User's NOAA email is Inactive in the staff directory")

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.

 

Reactivating user records in Alma

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:

  • the Status gets set back to Active
  • Expiration Date is removed
  • Purge Date is removed
  • EMAIL_INACTIVE user block is removed
  • Other fields like User Group and Line Office have been properly updated

(These settings are manually updated for Internal users.)

Merging patron records


Occasionally, we may find that we have more than one record for a single person. This could happen because:

  • In our old system, the person had records registered by two or more different libraries.
  • The patron's NOAA email address somehow didn't get entered into the Alternate ID 1 field.
  • The patron's NOAA email address has changed (perhaps due to a name change).

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.)

 

Using the patron load to identify accounts to merge

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:

  • Alma creates a new record for the new noaa.gov email ID
  • The old email ID "disappears" from the patron load, and gets reported as inactive.

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.

Deleting records based on the Patron Load


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.)