# Subworkflow – Remove WRLC Retention

This subworkflow removes WRLC retention commitments from a specified item by clearing retention-related fields in Alma for a given barcode and institution.

#### At a glance

- **Status:** Inactive ([parent workflows](https://alma-documentation-bookstack.azurewebsites.net/books/library-open-workflows/page/wrlc-retention) are Active)
- **Applies consortium-wide?:** Yes *(*
- **Runs on:** Alma Institution Zones via Network routing
- **Trigger:** Executed by another workflow (subworkflow only; no independent trigger)
- **Primary outcome:** Clears WRLC retention indicators from an item record in Alma.
- **Who receives results:** No direct output; results are returned to the calling workflow.

---

#### Why this exists

WRLC retention commitments are recorded at the item level in Alma. When a retention commitment needs to be removed (for example, as part of a broader retention management process), this subworkflow standardizes how those fields are cleared.

By isolating this logic into a reusable subworkflow, parent workflows can remove retention data consistently across institutions without duplicating code.

---

#### What it does

- Receives input from a [parent workflow](https://alma-documentation-bookstack.azurewebsites.net/books/library-open-workflows/page/wrlc-retention).
- Preserves the incoming barcode and institution code for error reporting.
- Routes the API call to the correct Alma Institution Zone.
- Retrieves the item by barcode.
- Clears WRLC retention-related fields.
- Writes the updated item back to Alma.
- Returns the updated item data to the calling workflow.

---

#### Where it runs

- **Alma IZ(s):**
    
    
    - Dynamically determined via `_institutionCode` passed from the parent workflow.
- **Systems touched:**
    
    
    - Alma APIs (item retrieval and update)
    - Alma Network routing node
- **Reports / queries used:** None

---

#### How it works

##### Logic overview

1\. Trigger (Subworkflow Execution)

- Starts via **“When Executed by Another Workflow.”**
- Requires input fields:
    
    
    - `Barcode`
    - `Institution Code`

If these fields are missing, the workflow will fail or route incorrectly.

---

2\. Preserve Input

The **“Stash barcode”** code node:

- Copies:
    
    
    - `Barcode`
    - `Institution Code`
- Stores them internally as:
    
    
    - `_inputBarcode`
    - `_institutionCode`

This ensures error reporting in the parent workflow can reference the original input values.

---

3\. Route to Correct Institution

The **Alma Network** node:

- Uses `_institutionCode` to dynamically select the appropriate Institution Zone.
- Does not target all network members.

⚠️ If `_institutionCode` is incorrect or missing, the update may fail or affect the wrong IZ.

---

4\. Retrieve Item

- Calls Alma API:
    
    
    - `GET /almaws/v1/items`
    - Uses the provided barcode.
- Always outputs data (even on error), allowing parent workflow error handling.

---

5\. Remove WRLC Retention Fields

The **“Remove WRLC Retention Code”** node modifies:

- `item_data.committed_to_retain`
    
    
    - Sets `value = false`
    - Sets `desc = "No"`
- `item_data.retention_reason`
    
    
    - Clears value and description
- `item_data.retention_note`
    
    
    - Clears value

⚠️ Important behaviors:

- This workflow **does not validate** whether the item is currently marked as WRLC retention.
- It forcibly clears the fields.
- It assumes the Alma item structure includes:
    
    
    - `item_data.committed_to_retain`
    - `item_data.retention_reason`

If Alma’s API structure changes, this logic may break.

---

6\. Update Item

- Calls Alma API:
    
    
    - `PUT /almaws/v1/bibs/{mms_id}/holdings/{holding_id}/items/{item_pid}`
- Writes the modified item back to Alma.

---

##### If results exist

- The item’s retention fields are cleared.
- The updated item JSON is returned to the parent workflow.
- No independent notification is sent.

##### If no results

- If the barcode is invalid or the item cannot be retrieved:
    
    
    - The workflow still outputs data (due to `continueRegularOutput` settings).
    - Error handling must be managed by the parent workflow.

---

#### Artifacts produced

- Updated Alma item record.
- No files, sets, reports, or email notifications.