Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    How to - A method of deleting user accounts from Alma which preserves original data in Alma Analytics

    Created By: Stacey van Groll
    Created on: 10/28/2018



    Use case

    As an Alma Administrator, I should be able to easily delete chosen user accounts from Alma while still maintaining data in Alma Analytics

    Goal

    Document a method for deleting selected user accounts from Alma which retains all user information in Alma Analytics for reporting and data analysis, including identifiers and user groups, in addition to supplementing with standardized purge information

    Summary

    • Configuration difficulty: Medium, as requires API calls
    • Consistency of outcome: Dependent on good data
    • Changes finalised: Dependent on local pre-deletion checks, number of records to run through the API, and data checks overnight by ETL (Extract, Transform, Load) to Alma Analytics.  API calls take approximately a second per account or 2-3 hours for around 10,000 users

    Local and Ex Libris Systems and Configuration

    • Alma and Alma Analytics
      • Delete User Policy – Keep Fully Reportable
      • Anonymization – False
    • LibNet – UQ staff intranet for documentation, on Confluence
    • Authentication Database and Memberships App – UQ local user management systems for staff and students and various community members respectively

    Procedures for Alma Admins

    • This procedure will be run once a year, after the Semester 1 Census Date
    • Repeat this process 4 times for each type of user: Non-Library Staff, Students, Library Staff, and Extramural
      • Each of these need specific checks and processes, particularly Library Staff
    • Identify user accounts in Analytics for purging
      • Expiry Date and Purge Date is less than or equal to the Census Date (eg 31.3.17), by appropriate User Group, and Note does not begin with 'User account purged'
      • Staff, Students, Library Staff: When terminated or expired as per Census Dates, the Expiry Date and Purge Date is set to the current date and Status set to Inactive in Alma
      • Extramural: When the expiry date is non-current in the Memberships App, the Expiry Date and Purge Date is set to the current date in Alma
    • Resolve any issues in Alma
      • Active balances owing (users)
      • Outstanding loans (library staff and users)
      • Assigned PO lines, POs, or invoices (library staff)
      • Locked bibliographic records (library staff)
      • Assigned import profiles (library staff)
      • Blocks on user accounts, with external blocks needing to be cleared
        • nb internal Library blocks will not cause the process to fail at any point
      • Check for test accounts and delete these directly in the user account, to ensure that the data isn't ETL'd to Analytics
      • Note: Patron management staff may choose to exclude some users from deletion on a discretionary basis by the type of outstanding issues, such as overdue High Use items
    • Export primary identifiers from Alma Analytics for users to be deleted as a txt file
    • Alert any required staff of work required the next day and delay the next step if they advise of any issues
      • Staff running API - for the Users API to be run to delete user accounts from Alma (split the file over two days if it will not complete in one day)
      • Staff managing Memberships app - for removal of extramural users from the Memberships app
      • Staff managing SIS - for removal of all users from the Authentication Database
    • Use the txt file to create an itemized set of Users by primary identifier in Alma with header of USERNAME
    • Document by exporting the set from Alma, add to the relevant entry in the Purge Records section on LibNet, and save a copy of the xls file
    • Wait until the 3 daily SIS jobs complete in Alma
      • These typically complete by 9:45am at the latest, but can take much longer on Monday mornings
    • Run an Update/Notify Users job on this set to:
      • Change first setting for "Added/changed field" from "By user account type" to "Internal"
      • Add an Expiry Date of the next day of the actual deletion eg 11.4.18
      • Add a Purge Date of the next day of the actual deletion eg 11.4.18
      • Set Status to Inactive. Note that this may already be Inactive for some accounts, which is fine
      • Add a Note in the following form, with the date the next day of the actual deletion ie note with 11.4.18 added on 10.4.18
        • User account purged 20180411
    • Wait overnight
    • The next morning, check Alma Analytics after ETL completion, and confirm that the changed data has been loaded by ETL
    • Wait until the 3 daily SIS jobs complete in Alma
      • These typically complete by 9:45am at the latest, but can take much longer on Monday mornings
    • Check the User set in Alma by exporting, sorting the Expiry Date by Date Oldest, and make sure all the Expiry Dates are still as changed in the Update/Notify Users Job the day before
      • Check both the beginning of the date column, and the end, for expiry dates earlier and later than anticipated
      • If the Expiry Date has changed, remove the primary identifier for that user from the txt file and remove the internal purge note from the user account in Alma
    • Send the file to staff managing SIS, and ask for checks on any active accounts in the Authentication Database and to delete the users
      • File specs: Remove the USERNAME header, plain text file, no delimiters separation, one primary identifier per line
      • If any identified, remove them from the txt file and remove the internal purge note from the user account in Alma
    • Send the same file to staff running the API and ask for run DELETE via the Users API
      • File specs: Remove the USERNAME header, plain text file, no delimiters separation, one primary identifier per line
      • nb the API will update the Expiry Date to the current date, but not the Purge Date
      • Script saved to Google docs: 20181028_AlmaDeleteUsersScript_UQ
    • If the users are Extramural, send the same file to staff managing the Memberships App, for removal of the users from the app as well
    • Document the details in LibNet of the finalised info in the Purge Records section, including details of dates, user tally, data variations, and a copy of the txt file
    • Check that the itemized set in Alma is empty, and delete the set
    • Wait overnight
    • The next morning, after the daily ETL is completed, check Alma Analytics and confirm that the account data is as below

    Standardized data changes as part of this process

    • After running the Update/Notify User job in Alma, the accounts in Alma will have the following characteristics immediately and Alma Analytics will have the following characteristics the next day:
      • Status: Inactive
      • Status Date: No change
      • Modification Date: Date of job run
      • Modified by: Update user information job
      • Expiry Date: Date of API call
      • Purge Date: Date of API call
      • User Note: User account purged Date of API call
    • After running the Delete User API, user accounts will no longer be present in Alma, but will have the following characteristics in Alma Analytics from the next day:
      • Status: Deleted
      • Status Date: Date of API call
      • Modification Date: Date of API call
      • Modified by: API, Ex Libris
      • Expiry Date: Date of API call
      • Purge Date: Date of API call
      • User Note: User account purged Date of API call

    Configuration Notes, including links to relevant Ex Libris OLH and Developer Network

    • Summary
      • If deleting users one by one in Alma - the Delete User Policy is ignored and all data is deleted in Analytics = BAD except for Library staff test accounts
      • Deleting users by Purge Users job - the Delete User Policy is triggered and all data will be Fully Reportable in Analytics = GOOD, BUT DANGEROUS as only by purge date and not specific Alma set of users
      • Delete by Users API the Delete User Policy is triggered and all data will be Fully Reportable in Analytics = GOOD
    • Fulfillment - Delete User Policy
      • This is set to Keep Fully Reportable and should NEVER be changed and updated via Save and Execute
      • If this is ever done, we will lose all user statistics from Analytics, which cannot be retrieved
      • "This configuration does not affect what happens when you manually delete users"
      • "Keep Fully Reportable – The user's status is Deleted; all requests are canceled, and the user identifier is deactivated. The rest of the user's data is retained in the system."
    • Ways to delete users
      • Delete User API
      • Purge users based on a set
        • Do NOT use the Purge Users job, as this can't be run on a set, instead is run by purge date only
      • Deleting users
        • Do NOT delete users in their account directly ie "When a user is deleted manually in Alma, it is fully deleted. No statistical or reportable data is maintained."
        • EXCEPTION: Delete test users directly in their accounts in Alma, to prevent the statistical data from ETL'ing to Analytics
      • Create user set in Analytics - includes details on set creation




    • Was this article helpful?