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 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.
-
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
_institutionCodepassed 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
_institutionCodeto 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
continueRegularOutputsettings). -
Error handling must be managed by the parent workflow.
-
Artifacts produced
-
Updated Alma item record.
-
No files, sets, reports, or email notifications.
No comments to display
No comments to display