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

1. Schedule Trigger

   • Role: Starts the workflow on a timed schedule.

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

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

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

4. Date in 18 Months (Date & Time → addToDate)

   • Role: Computes a date 18 months after today.

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

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