# 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 &amp; 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 &amp; Time → addToDate)**
    
    
    - Role: Computes a date 18 months after today.
5. **Unix Ms Date (Date &amp; 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