Trinity Students/Faculty update purge dates

Creates a set of non-expired patron accounts for Trinity University faculty and students in the Shared Collections Facility (SCF) IZ and updates their purge date to a date 18 months in the future. 

 At a glance 

 

 

 Status:  Active 

 

 

 Environment / Tags:  SCF Workflows; Live 

 

 

 Applies consortium-wide?:  No 

 

 

 Runs on:  SCF Production Alma environment 

 

 

 Trigger:  Scheduled — runs at  5:30 AM on the 1st day, every 4 months 

 

 

 Primary outcome:  Builds a current logical set of Trinity faculty/students and runs an Alma job to  set a purge date 18 months out  for those users. 

 

 

 Who receives results:  No direct distribution (no email/report delivery in workflow export) 

 

 

 Why this exists 

 Libraries often need user accounts to remain available for active patrons, while ensuring inactive/expired accounts are queued for cleanup according to policy. This workflow automates a repeatable “maintenance” step: it identifies current Trinity faculty/students (based on user group and expiry date) and sets a future purge date, reducing manual intervention and helping keep user data lifecycle rules consistent. 

 What it does 

 

 

 Runs on a schedule (every four months). 

 

 

 Captures  today’s date  in  YYYY-MM-DD  format. 

 

 

 Creates an Alma  logical set  named  Current Trinity Faculty and Students <YYYY-MM-DD> . 

 

 

 The set’s query targets Alma user records where: 

 

 

 user group is  Trinity Faculty  or  Trinity Student  ( tr fac  /  tr stud ),  and 

 

 

 expiry date is after today . 

 

 

 

 

 Calculates a date  18 months from today . 

 

 

 Converts that 18-months-from-now date into a  Unix millisecond timestamp . 

 

 

 Runs an Alma “Update/Notify Users – via API” job (job id  M148 ) against the created set. 

 

 

 Sets the job name dynamically to: Update/Notify Users - via API - <set name> 

 

 

 Updates  only  the user  Purge Date  (enabled), leaving other update options disabled. 

 

 

 Where it runs 

 

 

 Alma IZ(s):  Shared Collections Facility (SCF) Institution Zone 

 

 

 Systems touched: 

 

 

 Alma APIs  (Ex Libris Alma REST APIs) — used here to create a logical set and run a configured Alma job. 

 

 

 

 

 Reports / queries used: 

 

 

 Alma logical set query (embedded in the set creation): 

 

 

 USER where USER ((user_group OUTER_EQUAL (tr fac or tr stud)) AND USER (expiry_date AFTER <today>)) 

 

 

 

 

   

 

 

 How it works 

 Logic overview 

 Execution order (nodes): 

 

 

 Schedule Trigger 

 

 

 Role: Starts the workflow on a timed schedule. 

 

 

 Key behavior: “Runs at 5:30am on day 1 every 4 months.” 

 

 

 

 

 Today’s Date (Date & Time → formatDate) 

 

 

 Role: Produces today’s date formatted as  yyyy-MM-dd . 

 

 

 Output used in the set name and set query. 

 

 

 

 

 Create Logical Set (Alma API → POST /almaws/v1/conf/sets) 

 

 

 Role: Creates a logical set of current Trinity faculty/students. 

 

 

 Key configuration: 

 

 

 Set name pattern:  Current Trinity Faculty and Students <today> 

 

 

 Type:  LOGICAL 

 

 

 Content:  USER 

 

 

 Query: Trinity faculty/student user groups with expiry date after today 

 

 

 

 

 Credential label referenced:   SCF Production - Alma APIs - Read & Write 

 

 

 

 

 Date in 18 Months (Date & Time → addToDate) 

 

 

 Role: Computes a date 18 months after today. 

 

 

 

 

 Unix Ms Date (Date & Time → formatDate) 

 

 

 Role: Converts the 18-month future date into a Unix millisecond timestamp ( x ). 

 

 

 Output feeds the purge date value used by the Alma job. 

 

 

 

 

 Run Job (Alma API → POST /almaws/v1/conf/jobs/{job_id} with op=run, job_id=M148) 

 

 

 Role: Runs an Alma job against the logical set, updating user fields. 

 

 

 Key configuration that affects behavior: 

 

 

 Targets  set_id  from “Create Logical Set” 

 

 

 Purge Date update is enabled  ( UPDATE_User_Information_Purge_Date_Active = true ) 

 

 

 Purge date value is the Unix ms timestamp for “today + 18 months” 

 

 

 Most other update options are explicitly disabled (e.g., status/user group/roles/notifications are not activated) 

 

 

 

 

 

 

 If results exist 

 

 

 Alma creates the logical set with matching users, then runs the job on that set. 

 

 

 For each user in the set, the job updates the  Purge Date  to  18 months from the run date  (expressed as a Unix ms timestamp in the job parameters). 

 

 

 If no results 

 

 

 The workflow still creates the logical set and runs the Alma job. 

 

 

 Expected behavior is that the job completes with  0 affected records  (no special branching, alerts, or alternate path in the workflow export). 

 

 

 Artifacts produced 

 

 

 Alma logical set  created each run: 

 

 

 Naming pattern:  Current Trinity Faculty and Students <YYYY-MM-DD> 

 

 

 

 

 No files, emailed outputs, or stored reports are produced by this workflow