Skip to main content

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