Deactivating vs Deleting User Records

What to do when a patron leaves NOAA

---

The patron load monitors which accounts are active in the NOAA staff directory on a weekly basis.

When the patron load detects that a record is no longer active, we make the record Inactive in Alma and set some additional parameters to make sure that Alma does not automatically allow the patron to still check out materials.

At this point, typically:

• The patron's noaa.gov email is no longer active
• The patron no longer has an active appointment.

However, for many patrons:

• the patron may be between contracts, and may return under a new contract shortly
• the patron may start a new position within NOAA within the next few weeks or months
  • Sometimes, this may be under a different line office or in a different part of the country

Because of this, we often end up reactivating some records later.

Fields that Alma uses to identify records for patrons who have left NOAA

---

Status (Active vs Inactive)

Alma uses the Status field to identify:

• When requests for authentication (for password-based authentication only) should be rejected
  • Inactive records won't authenticate using internal (non-SSO) authentication
• When a loan should automatically be blocked or require an override

Expiration Date

Alma uses the Expiration Date to identify:

• When is the last possible due date for a loan or renewal
• When requests for authentication (for password-based authentication only) should be rejected
  • Note that Inactive records also won't authenticate using internal (non-SSO) authentication

Purge Date

Alma uses the Purge Date to identify:

• Whether it's okay to purge a record (on request) based on the number of days since the purge date in the record

Note: Users with no purge date in the record are never purged

Deactivate or Delete the Record?

---

When we purge a user record in Alma, the system irrevocably anonymizes any remaining record data, and we can no longer look up that record.  This can make it difficult (or impossible) to identify changes or reinstate settings should a patron return later.  (See also the difference between "purging" and "deleting" below.)

However, there are other ways that we can make it so that Alma no longer shows the record in patron lists or allows the patron to check out materials.

In general, we tend to make records Inactive when patrons leave, and then delete them only after a certain amount of time (e.g., one year) has passed.

 

How we deactivate records

When we deactivate a record, we typically run an Update Users job on a set of accounts to be deactivated.  For each record we:

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

These settings let Alma know that the user shouldn't be able to check things out or log into Alma, and let library staff know why the account has been deactivated.

We can reactivate the account by reloading the record from the patron load (if it is an External record), or by manually reversing these changes (for Internal records).

 

Benefits of deleting defunct accounts (after a year)

• Removal of potentially identifying information for people who have long since left
  • (at which point it's hard to identify a business case for keeping that information)
• Some minor streamlining of reporting
  • (mostly we exclude inactive patrons from reports and lists where we want information on current patrons, though)
• Having fewer defunct records in the Manage Users list

Downsides to deleting inactive accounts

• Some information gets removed from the database and can no longer be used as a statistical input
  • (e.g., if we wanted to use the zip code or area code for an analysis)
  • Note that deleting records manually from Manage Users deletes all fields (even non-identifying statistical fields)
• If a patron later returns to NOAA, we would no longer have:
  • their original password
  • historical information specific to that individual patron (like past blocks and notes, or which Line Office they used to work in)
  • saved settings like notification preferences, or saved searches in Primo

 

Deleting records vs Purging Records

---

In general, "purging" user records in Alma can be thought of as a batch deletion process.  However, there are a couple of important differences.

Purge User Records

Purge User Records is a type of batch job that runs against the all of the records of a particular User Group in Alma. It checks the records to make sure that they have a purge date that falls under the criteria of the purge job before deleting them.  When it deletes records, it follows our Delete User Policy settings, anonymizing the record and and retaining only non-identifying statistical fields.

Records deleted using Purge User Records can still be reported upon, although many of the fields are no longer present.

Delete User

When we delete a user from the record actions in Manage Users, Alma deletes the record completely. It does not consult our Delete User Policy settings at all.

No statistical fields are retained at all, and the record can no longer be reported on in Alma Analytics.

When we merge users, it counts as though we have manually deleted the old user account. (However, we can choose to migrate some or all of the information in the deleted record to the new record.)

All Deletion Methods

All of the user account deletion methods we have perform some basic checks to make sure that the account can be deleted. In particular:

• For all patrons:
  • They do not have outstanding loans.
  • The user record is not currently locked by a running job.
  • They do not have a balance due on their account.
    (We don't typically issue fines, so this one is unlikely to be an issue.)
• For users with library staff roles:
  • They do not have any assigned PO lines, POs, or invoices.
  • They do not have any locked bibliographic records.
  • They do not have any assigned import profiles.
  • They are not currently working in the MD Editor.

Note that Purge Users will also require the patron to have a Purge Date in their record (even if the "Number of Days After Purge Date" field is set to 0), but Delete User will not look at the Purge Date field.

Procedures for Batch-Deleting (Purging) Defunct User Records

---

Because we monitor how long records have been inactive in the patron load process, we are able to create sets for purging records based on how many weeks it has been since a record was last active*. However, we can also use this process for smaller or ad-hoc batches.

* Currently we have proposed purging inactive records that have not been active in the staff directory for more than one year.

1. Create an itemized set of the user records to be purged.
2. Change the user group of those records to "Purge User Account"
   • This is a special user group just for records that we plan to purge within the next couple of days.
3. Check the user records to make sure that they are ready for deletion
   (this can be done individually or, if we can wait overnight first, in Alma Analytics)
   • Make sure there are no current or outstanding loans
     (the deletion process won't let us delete these anyways, but it's cleaner to remove them from the deletion queue first)
   • Make sure all of the records have purge dates
4. If any records are not ready for deletion, change the user group back to another user group.
5. Create a job in Admin > User Management > Purge User Records:
   • User Type: Public
   • User Group: Purge User Account
   • Number of Days After Purge Date: (depends on your set; just make sure it's in the past)
6. Run the job.
7. Check the job completion status:
   • If the job says "Completed with no Bulks" then 0 records were processed -- review the criteria and fields in the records
   • If the job says "Completed Successfully", then it will report on the number of records that passed validation and that were successfully deleted.