Workflow Catalog

This chapter provides a comprehensive catalog of automated workflows and cloud applications built by the WRLC HQ.

CU Law: New Borrowing Request Notification

Notifies CU Law staff when an ILL request is submitted via Primo.

At a glance

Why this exists

When a patron submits an interlibrary loan request through Primo, Alma creates the borrowing request, but staff may not see it until they manually check Alma. This workflow closes that gap by sending an email notification as soon as a qualifying new borrowing request is created. For member library staff, that means faster response time and less repeated checking of Alma when nothing new has arrived.

What it does

Where it runs

How it works

Artifacts produced:
The output is an HTML email notification sent to the shared inbox.

Delete NZ Bib Set

Form accepts an NZ Set ID, displays a deletion review screen with record count, and submits Alma’s Delete Bibliographic Records job (M28) to permanently remove all records in that set.

At a glance

Why this exists

Network Zone cleanup workflows often produce itemized bibliographic sets that are ready for deletion after review. Rather than requiring staff to manually navigate Alma job screens, this workflow provides a controlled, review-based interface to:

It centralizes destructive actions behind a visible approval step.

What it does

Where it runs

Credential referenced:

How it works

Logic overview

1. Form Submission

The workflow begins with the form:

Delete NZ Bibliographic Set

Required field:

The description indicates this Set ID may come from a LibOW email notifying staff that a set is ready for deletion.

2. Retrieve Set

The workflow calls:

GET /almaws/v1/conf/sets/{set_id}

If retrieval fails:

If retrieval succeeds:

3. Review Screen (Manual Approval Step)

The review form displays:

⚠️ Current safeguards:

Approval is implicit by proceeding.

4. Submit Deletion Job

The workflow submits Alma Job M28 (Delete Bibliographic Records) with:

This deletes all bibliographic records in the set without handling inventory or related bibs.

5. Completion Message

The final screen displays:

“The set is currently being deleted in the NZ.”

No email confirmation is sent.

If results exist
If no results

Artifacts produced

DRAFT Scan In Consortial Barcode

At a glance

· Status: Inactive / not yet built for production use
· Environment / Tags: Community Use Case
· Applies consortium-wide?: Yes
· Runs on: Member Alma institutions
· Trigger: Staff submit a form with an item barcode
· Primary outcome: Eventually, this workflow will scan in a WRLC item automatically at the circulation desk where the user is physically located.
· Who receives results: The staff member submitting the form sees either a success or error message.

Why this exists

This workflow is intended to make it faster and easier for member library staff to scan in consortial items. Instead of manually determining where an item belongs, staff would enter or scan a barcode into a simple form. The workflow would then identify the item and scan it in through Alma.

This workflow is different from other cataloged workflows because it is not ready for rollout yet. WRLC has requested an update to the CloudApp form API so the form submission can include the user’s location. That location is needed so the item can be scanned in at the correct circulation desk automatically.

What it does

· Presents a simple form titled “Scan in Consortial Barcode.”
· Collects one input from the user: Barcode.
· Uses the barcode prefix to identify the owning WRLC institution.
· Looks up the item in Alma; uses network-level Alma logic to retrieve item information from the owning institution.
· Then accesses the user's Institution Zone in Alma; scans the item in using Alma’s item scan-in API.
· Shows a success message if the scan-in step completes.
· Shows an error message if the item lookup encounters an Alma error.
· Currently uses a placeholder circulation desk value, so it cannot fully function as intended until user location is available from the form API.

Where it runs

· Alma IZ(s): Multiple WRLC member institutions, determined by barcode prefix and location of user
· Systems touched: Alma APIs 
· Reports / queries used: None
· Credentials referenced:
· NZ Production - Alma APIs - Read & Write

How it works

Logic overview

· If the barcode maps to a WRLC institution: the workflow assigns the matching institution code and continues to item lookup.
· If the item is found: the workflow retrieves bibliographic, holdings, and item data, then attempts to scan in the item.
· If scan-in succeeds: the user sees a success screen.
· If Alma returns an error during item lookup: the user sees an error screen with the Alma error message.

Artifacts produced: None.

Pending dependency

Full rollout depends on a CloudApp form API update that provides user location at form access time. This location will be used to determine the circulation desk for scan-in.

“Identify CZ records wo inventory, not used by Network” job

Runs biweekly to identify the set created by the Alma NZ job “Identify records that are not used in the Network - NZ titles linked to CZ, no NZ inventory”, then emails the NZ Manager a review-and-approval link for potential deletion.

At a glance

Why this exists

Over time, the Network Zone can accumulate bibliographic records that:

These records may be candidates for cleanup. This workflow does not delete records directly. Instead, it:

This separates identification from deletion, creating a manual approval checkpoint.

What it does

Where it runs

Credential referenced:

How it works

Logic overview

1. Scheduled Trigger

2. Retrieve Identification Job Instances

The workflow retrieves instances of Alma job:

S31366584960004101

Date range:

It explicitly checks both statuses:

This ensures no run is missed due to job outcome.

⚠️ If the job ID changes, this workflow will stop functioning.

3. Filter for Correct Job

A Filter node ensures only jobs whose name contains:

“Identify records that are not used in the Network - NZ titles linked to CZ, no NZ inventory”

If Alma job naming changes, this filter may fail.

4. Retrieve Set Created by Job

The workflow:

It then retrieves full set information, including:

⚠️ Assumes set naming convention includes job counter value.

5. Send Notification Email

An email is sent to the WRLC Consortial NZ Manager

Email includes:

The email clearly states:

If no action is taken, no deletion will occur.

Deletion requires manual approval via the separate workflow.

If results exist
If no results

Artifacts produced

Relationship to other workflows

This workflow depends on:

This workflow only performs identification and notification.

“Identify non-CZ e-book wo inventory, not used by Network” Job

Runs biweekly to identify the set created by the Alma NZ job “Identify records that are not used in the Network - NZ Book - Electronic records without inventory, non-CZ”, then emails the NZ Manager a review-and-approval link for potential deletion.

At a glance

Why this exists

The Network Zone can accumulate electronic bibliographic records that:

These records may be candidates for cleanup.

This workflow does not delete records automatically. Instead, it:

This separation ensures deletion remains a deliberate, manual action.

What it does

Where it runs

Credentials referenced:

How it works

Logic overview

1. Scheduled Trigger

2. Retrieve Identification Job Instances

The workflow retrieves instances of Alma job:

S31366564050004101

Date range:

It checks both:

This ensures the workflow captures job runs regardless of outcome.

⚠️ If the job ID changes, the workflow will no longer retrieve the correct instances.

3. Filter for Correct Job

A Filter node ensures only jobs whose name contains:

“Identify records that are not used in the Network - NZ Book - Electronic records without inventory, non-CZ ”

This prevents accidental processing of unrelated jobs.

⚠️ If the Alma job name wording changes, the filter may fail.

4. Retrieve the Set Created by the Job

The workflow:

It then retrieves:

⚠️ This assumes the Alma job’s set naming convention includes the job counter value.

5. Send Notification Email

An email is sent to the WRLC Consortial NZ Manager

The message includes:

The email clearly states:

If no action is taken, no deletion will occur.

Deletion requires manual approval via the separate workflow.

If results exist
If no results

Artifacts produced

Relationship to other workflows

This workflow is part of a cleanup chain:

  1. Alma scheduled job creates the identification set.

  2. This workflow sends notification and approval link.

  3. Delete NZ Bib Set workflow performs deletion after manual approval.

This ensures identification and deletion are separated by human review.

OCLC Job Reports

Gathers job report statistics from Network Zone import profiles (specifically OCLC Overlay import profiles) and places them into an Excel spreadsheet on a daily basis.

At a glance

Why this exists

WRLC staff need a reliable, low-effort way to track how daily OCLC bibliographic overlay jobs are performing over time. This workflow makes that work visible and auditable by automatically capturing key job statistics (record counts and match outcomes) and logging them in a shared spreadsheet, creating a historical record without manual data gathering.

What it does

Where it runs

How it works

Logic overview

Execution flow (plain language):

  1. Scheduled trigger

    • The workflow starts every day at 3:45 AM.

  2. Determine reporting date

    • Calculates yesterday’s date in YYYY-MM-DD format.

  3. Retrieve import profiles

    • Pulls all REPOSITORY-type import profiles from the Alma Network Zone.

  4. Profile filtering

    • Keeps only profiles whose name contains “OCLC Daily Bib Overlay”.

    • Keeps only profiles that are active.

  5. Retrieve job instances

    • For each qualifying import profile:

      • Retrieves job instances submitted yesterday

      • Limits results to jobs with status COMPLETED_SUCCESS

  6. Instance cleanup

    • Removes job instances whose names contain “w/FTP”.

    • Removes duplicate instances to avoid double-counting.

  7. Retrieve job details

    • Fetches full details for each remaining job instance.

  8. Extract reporting fields

    • Pulls and normalizes:

      • Job name

      • Status and status date

      • Total records processed

      • Single matches

      • Multiple matches

      • Records not matched/imported

  9. Write to Excel

    • Appends a new row to a shared Excel table, mapping:

      • Job name → import type (New, Updated, Merged, Deleted)

      • Status date → reporting date

      • Counters → match and record totals

If results exist
If no results
Artifacts produced

OCLC Multi Match List Page

Automatically generates a daily Excel report of all OCLC multi-match bibliographic records from the previous day’s NZ import jobs.

At a glance

Why this exists

When OCLC import jobs encounter multi-matches, Alma cannot automatically determine which existing record should be updated. These records require review.

This workflow creates a structured, review-ready spreadsheet listing all multi-match records from the previous day’s OCLC import jobs, including:

This supports consortium-level quality control and faster resolution of ambiguous matches.

What it does

Where it runs

How it works

Logic overview

1. Schedule & Date Setup

2. Identify Relevant Import Jobs

⚠️ If import profile IDs change, this workflow must be updated.

3. Retrieve Multi-Match Records

⚠️ If naming conventions change, import type detection may break.

4. Separate Network IDs

5. Retrieve and Parse Bib Records

For each Network ID:

Returns one row per AVA field (institution holding).

⚠️ Assumptions:

6. Normalize and Deduplicate

7. Excel Output

For each run:

  1. Creates a new worksheet named with yesterday’s date (yyyy-MM-dd).

  2. Waits 15 seconds (ensures Excel sheet creation completes).

  3. Appends a header row.

  4. Creates a table.

  5. Appends all processed rows.

Columns written:

Network IDs and MMS IDs are written as text to prevent numeric reformatting.

If results exist

If no results

Artifacts produced

No emails or additional reports are generated.

SCF - Add More Collection Items

At a glance

Status: Active

Environment / Tags: SCF Workflow

Applies consortium-wide?: No / likely institution-specific
Inferred: The workflow appears to be specific to SCF because the workflow name, tag, and Alma credentials all reference SCF. The export does not show a broader consortium-wide tag or multiple institution-specific branches.

Runs on: SCF Production Alma tenant / IZ
Inferred: The workflow uses credentials named “SCF Production - Alma APIs - Read Only” and “SCF Production - Alma APIs - Read & Write.” The export does not explicitly list an Alma institution code or IZ name.

Trigger: Manual web form submission. A staff user submits a form titled “Add More Collection Items” with a required Model Barcode field.

Primary outcome: Creates a new Alma item record on the same bibliographic record and holding as an existing “model” item, using selected values entered or edited by the staff user.

Who receives results: The person using the form sees either a success message or a barcode error message in the form interface. No email recipients are listed.

Why this exists

This workflow helps staff create additional special collections item records in Alma when those new items should be attached to an existing bibliographic record and holding. Instead of requiring staff to manually build the new Alma item from scratch, the workflow uses an existing item as a model, copies its Alma structure, removes system-specific fields that should not be reused, and applies a new barcode and selected description/enumeration values.

Member libraries should care because this makes SCF collection maintenance more consistent, reduces repetitive cataloging work, and lowers the risk of creating new item records on the wrong bibliographic or holdings record.

What it does

Where it runs

Alma IZ(s): SCF Production Alma tenant / IZ
Inferred: The workflow export identifies SCF Production credentials but does not explicitly state an Alma institution code or IZ name.

Systems touched:

Reports / queries used: None.
The workflow does not use Alma Analytics reports or saved queries.

Credentials referenced:

No secrets, tokens, or API keys are included here.

How it works

Logic overview

  1. On form submission
    The workflow begins when a user submits the Add More Collection Items form with a required Model Barcode.
  2. Retrieve item using barcode
    The workflow searches Alma for an item matching the submitted model barcode.
  3. Barcode error path
    If Alma returns an error, the workflow sends the user to a Barcode error response page. The message displays the Alma error text and offers a restart form button.
  4. Prepare Review Form
    If the barcode lookup succeeds, the workflow extracts useful values from the model item, including:
    • collection title
    • original barcode
    • alternative call number
    • internal note 1
    • enumeration A
    • enumeration B
    • chronology I
    • chronology J
    • description
    • MMS ID
    • holding ID

  5. Review/edit form
    The workflow displays a second form asking the user to provide or confirm the new item’s:

    • new barcode
    • enumeration A
    • description

    The form description shows the collection title, MMS ID, and holding ID for context.

  6. Normalize Submitted Item Fields
    The workflow trims spaces from the submitted values and requires the new barcode to be present.
  7. Retrieve Item 2
    The workflow retrieves the original model item again using the original barcode.

  8. Build Create Payload
    The workflow copies the model item, removes system fields that should not be reused, and then applies the new submitted values.

    Removed system fields include:

    • item PID
    • item barcode from the model record

    Replaced or updated fields include:

    • barcode
    • enumeration A
    • description
  9. Create Item
    The workflow posts the new item to Alma using the model item’s MMS ID and holding ID.
  10. Success response
    The workflow displays a success page confirming that another item record was created and showing the new barcode.

If results exist

If Alma finds the model barcode, the workflow continues to the review form, lets the user enter the new item details, and then creates a new Alma item record attached to the same bib and holding as the model item.

If no results exist

If Alma cannot retrieve an item for the submitted model barcode, the workflow follows the error path and displays a Barcode error response. The export does not define a separate “no results” branch; failed lookup behavior is handled through the Alma API error output.

Artifacts produced

Alma item record: A new item record is created in Alma.

Files or reports: None.

Email output: None.

Naming pattern: No report or file naming pattern is present in the workflow export.

Inferences / verification notes

SCF - Publish Items to the SCF IZ via File Upload

At a glance

Why this exists

This workflow supports SCF processing by giving staff a structured way to publish batches of member-library items into the SCF Institution Zone when the remote storage app has failed to publish them. Instead of processing items one at a time, staff can upload a text file of barcodes and let the workflow check, copy, and report on the results.

What it does

Where it runs

How it works

Logic overview
Artifacts produced

SCF - Update Internal Note 1

A form is used to input and update the Internal Note 1 field in both the Shared Collections Facility (SCF) IZ and the IZ that owns the item.

At a glance

Why this exists

Shared Collections Facility (SCF) staff need a fast, reliable way to record tray location information on physical items in both the SCF Institution Zone and the IZ of the Owning Institution. This workflow provides a simple form-based tool that updates the Alma item’s Internal Note 1 and Item Call Number field without requiring staff to navigate full Alma item editing screens, while also keeping owning institutions’ records in sync when appropriate. However, this needs to be two separate workflows for quality control.

What it does

Where it runs

How it works

Logic overview

Execution flow (plain language):

  1. Form submission

    • Staff submit a barcode via a web form titled “Update Internal Note 1.”

  2. Retrieve item using barcode

    • Alma API retrieves the item record from SCF.

    • If the barcode is invalid or not found, the workflow stops and shows an error.

  3. Owning IZ check

    • The workflow checks the item’s provenance value.

    • If the provenance matches a known WRLC member IZ code, the item is treated as having an owning IZ.

    • Otherwise, it is treated as an SCF-only item.

  4. Tray location entry

    • Staff are prompted to enter a Tray Location, with the item title shown for confirmation.

  5. Update logic

    • The tray location is written to item_data.internal_note_1.

    • For SCF-only items:

      • The item is updated in SCF only.

    • For items with an owning IZ:

      • The item is updated in SCF.

      • The workflow retrieves the owning IZ’s item record and updates it as well.

  6. Completion

    • A success message confirms where the update occurred.

    • If the SCF update succeeds but the owning IZ update fails, a partial-success error message is shown.

If results exist
If no results
Artifacts produced

SCF - Update Internal Note 3

A form is used to input and update the Internal Note 3 field in the Shared Collections Facility (SCF) IZ only for local informational purposes.

At a glance

Why this exists

Shared Collections Facility (SCF) staff need a fast way to put notes about the current status and whereabouts of an item in the SCF processing area. This workflow provides a simple form-based tool that allows better internal tracking.

What it does

Where it runs

How it works

Logic overview

Execution flow (plain language):

  1. Form submission

    • Staff submit a barcode via a web form titled “Update Internal Note 3.”

  2. Retrieve item using barcode

    • Alma API retrieves the item record from SCF.

    • If the barcode is invalid or not found, the workflow stops and shows an error.

    •  

  3. Tray location entry

    • Staff are prompted to enter note text, with the item title shown for confirmation.

  4. Update logic

    • The tray location is written to item_data.internal_note_3in the SCF IZ

      • The item is updated in SCF only.

       

  5. Completion

    • A success message confirms where the update occurred.

If results exist
If no results
Artifacts produced

SCF - Update Item Call Number

A form is used to input and update the Item Call Number field in both the Shared Collections Facility (SCF) IZ and the IZ that owns the item.

At a glance

Why this exists

Shared Collections Facility (SCF) staff need a fast, reliable way to record tray location information on physical items in both the SCF Institution Zone and the IZ of the Owning Institution. This workflow provides a simple form-based tool that updates the Alma item’s Internal Note 1 and Item Call Number field without requiring staff to navigate full Alma item editing screens, while also keeping owning institutions’ records in sync when appropriate. However this needs to be two separate workflows for quality control.

What it does

Where it runs

How it works

Logic overview

Execution flow (plain language):

  1. Form submission

    • Staff submit a barcode via a web form titled “Update Item Call Number.”

  2. Retrieve item using barcode

    • Alma API retrieves the item record from SCF.

    • If the barcode is invalid or not found, the workflow stops and shows an error.

  3. Owning IZ check

    • The workflow checks the item’s provenance value.

    • If the provenance matches a known WRLC member IZ code, the item is treated as having an owning IZ.

    • Otherwise, it is treated as an SCF-only item.

  4. Tray location entry

    • Staff are prompted to enter a Tray Location, with the item title shown for confirmation.

  5. Update logic

    • The tray location is written to item_data.alternative_call_number.

      • **note - item call number field was originally called alternative call number in early Alma releases and that name persists in the data library

    • For SCF-only items:

      • The item is updated in SCF only.

    • For items with an owning IZ:

      • The item is updated in SCF.

      • The workflow retrieves the owning IZ’s item record and updates it as well.

  6. Completion

    • A success message confirms where the update occurred.

    • If the SCF update succeeds but the owning IZ update fails, a partial-success error message is shown.

If results exist
If no results
Artifacts produced

SCF - Spreadsheet of exported SCF Requests

At a glance

· Status: Active
· Environment / Tags: Live; SCF Workflow
· Applies consortium-wide?: Shared Collections Facility IZ only
· Runs on: Alma APIs
· Trigger: Staff submit an authenticated form
· Primary outcome: Creates and emails a spreadsheet of recent SCF request exports.
· Who receives results: The email address entered in the form

Why this exists

This workflow lets staff quickly receive a spreadsheet of recent requests for SCF materials without manually checking multiple SFTP folders or parsing Alma request export files. It supports visibility into requests sent to SCF and helps staff confirm what Alma processed during recent “Send Requests to Remote Storage” job runs.

What it does

This workflow lets staff request a spreadsheet of recent SCF material requests. A staff member selects a time period and enters an email address. The workflow then looks for SCF request files from that period, turns the request data into a spreadsheet, and emails it to the requester.

If no recent request files are found, the workflow tells the user that no requests were found instead of sending a blank spreadsheet.

Where it runs

· Alma IZ(s):SCF IZ
· Systems touched:
· n8n form
· WRLC SFTP server
· Alma remote storage request export files
· Gmail
· Credentials referenced:
· WRLC SFTP server
· Gmail Credentials - Generic LibOW

How it works

Logic overview
  1. A staff member submits the WRLC SCF Requests form.
  2. The workflow reads the selected time period.
  3. It calculates a cutoff timestamp based on that time period.
  4. It formats today’s date for use in the email subject.
  5. It creates a list of SCF SFTP request folders to check.
  6. It lists files in each folder.
  7. It filters the results to keep only recent files modified after the cutoff time.
  8. The workflow checks whether any matching files were found.
  9. If files were found:
    • It downloads the request files from SFTP.
    • It extracts XML content from the files.
    • It transforms the XML into request text.
    • It parses that text into structured request fields.
    • It converts the parsed data into an Excel spreadsheet.
    • It emails the spreadsheet to the address submitted in the form.
    • It displays a success message.
  10. If no files were found:
Artifacts produced

· Spreadsheet attachment: SCF Requests
· Email subject pattern: Incoming SCF Requests yyyy-MM-dd
· Email recipient: The address entered in the form

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

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

Where it runs

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
If no results

Artifacts produced

WRLC Retention

Processes a user-uploaded CSV of barcodes to bulk add or remove WRLC retention commitments across institutions, then emails a summary of results.

At a glance

Why this exists

WRLC retention commitments must be applied or removed at scale when retention decisions change. Performing this manually in Alma would require record-by-record updates across multiple institutions.

This workflow enables controlled bulk processing by:

It centralizes retention management while preserving audit visibility.

What it does

Where it runs

How it works

Logic overview

1. Form Submission

The workflow begins with a form requiring:

Required CSV format:

Barcode Institution Code

⚠️ The workflow does not validate header names; it assumes:

2. Row Counting & Review Step

Before processing:

This confirmation step prevents accidental bulk updates.

3. Branch Based on User Selection

An If node evaluates the dropdown choice:

Each CSV row triggers one subworkflow execution (mode: each).

⚠️ Errors are set to continueRegularOutput, meaning:

4. Subworkflow Processing

Each row:

(Full logic documented in the respective subworkflow entries, Add WRLC Retention and Remove WRLC Retention)

5. Aggregate Results

After all rows are processed:

The Summarize results node:

Errors are retained even if barcode is missing.

6. Email Results

Sends an HTML-formatted email containing:

From address: reports@wrlc.org
Recipient: Email provided in form

If results exist
If no results

Artifacts produced

Subworkflow – Add WRLC Retention

This subworkflow applies a WRLC retention commitment to a specified item by setting the retention-related fields in Alma for a given barcode and institution.

At a glance

Why this exists

WRLC retention commitments are recorded at the item level in Alma using structured retention fields. When an item is designated for WRLC retention, those fields must be set consistently across institutions.

This subworkflow standardizes how retention commitments are applied, ensuring that parent workflows can add WRLC retention flags in a consistent and reusable way without duplicating logic.

What it does

Where it runs

How it works

Logic overview

1. Trigger (Subworkflow Execution)

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

2. Preserve Input

The “Stash barcode” code node:

This ensures the calling workflow can reference the original input values for error handling or reporting.

3. Route to Correct Institution

The Alma Network node:

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

4. Retrieve Item

5. Apply WRLC Retention Fields

The “Add WRLC Retention Code” node updates:

⚠️ Important behaviors:

If Alma’s API structure changes, this node may fail.

6. Update Item

If results exist
If no results

Artifacts produced

Subworkflow - Create Items in SCF IZ

At a glance

· Status: Active
· Environment / Tags: SCF Workflow
· Applies consortium-wide?: No, specific to Shared Collections Facility Institution Zone
· Runs on: SCF Production Alma IZ
· Trigger: Runs only when called by another workflow
· Primary outcome: Creates or locates an SCF IZ bib/holding, then creates an item in that holding.
· Who receives results: Returns a success or error result to the calling workflow.

Why this exists

This subworkflow supports shared print / SCF item creation by moving item data from a calling workflow into the SCF Alma institution zone. It helps ensure that an item can be represented in SCF with the correct bib, holding, location, provenance, and barcode pattern.

What it does

Where it runs

· Alma IZ(s): SCF Production Alma IZ
· Systems touched: Alma APIs
· Credentials referenced: SCF Production - Alma APIs - Read & Write
· Reports / queries used: None

How it works

Logic overview
  1. Search for the bib in the SCF IZ
  2. If a matching SCF bib is found: the workflow retrieves that bib, checks for an SCF holding at the requested location, creates a holding if needed, then creates the item.
  3. If no matching SCF bib is found but the source is NZ-linked: the workflow creates an SCF IZ bib from the NZ MMS ID, then creates the holding and item.
  4. If no matching SCF bib is found and the source is not NZ-linked: the workflow creates a new SCF IZ bib from the supplied bib record, adds a local 035 field, then creates the holding and item.
  5. If an Alma create step fails: the workflow returns an error result with the barcode, error type, and error message.
  6. If item creation succeeds: the workflow returns the barcode and successfully imported.

Artifacts produced: No files or reports. The output is structured JSON returned to the calling workflow.

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

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

Where it runs

How it works

Logic overview

1. Trigger (Subworkflow Execution)

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

2. Preserve Input

The “Stash barcode” code node:

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

3. Route to Correct Institution

The Alma Network node:

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

4. Retrieve Item

5. Remove WRLC Retention Fields

The “Remove WRLC Retention Code” node modifies:

⚠️ Important behaviors:

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

6. Update Item

If results exist
If no results

Artifacts produced

WRLC - Journal Volume Overlap Tool

At a glance

Why this exists

When processing journal volumes for accession into the Shared Collections Facility (SCF), staff need to quickly determine whether volumes of the same title are already held.

This workflow provides a fast, self-service lookup tool that eliminates the need for manual searching across Alma. It helps staff:

What it does

Where it runs

How it works

Logic overview

  1. User submits the form with either a barcode or ISSN
  2. Workflow checks whether the barcode field is empty
  3. Branches into one of two paths:

Barcode path

ISSN path

If results exist

If no results

Artifacts produced

WRLC - Retention Copy Analysis Tool

At a glance

Why this exists

When evaluating retention commitments across the consortium, staff need to understand how many copies of a title exist and which institution is responsible for retaining them.

This workflow provides a quick way to analyze all copies tied to the same Network ID (i.e., the same bibliographic record or edition). It helps staff:

What it does

Where it runs

How it works

Logic overview

  1. User submits a barcode via the form
  2. Workflow runs Barcode Lookup report to retrieve item data
  3. Extracts the Network ID from the result
  4. Runs a second Analytics query using that Network ID to find all related copies
  5. Branches based on whether the Network ID lookup succeeds

If results exist

If no results

Artifacts produced

 

Update Item Description with Excel

At a glance

Why this exists

Staff sometimes need to update item description fields in bulk, especially for serials, multipart items, or other records where description, enumeration, and chronology need to be corrected or added consistently. Doing this one item at a time in Alma is slow and error-prone. This workflow provides staff at HQ an upload form that applies those updates via the Network Zone in bulk for a selected Institution Zone, and then emails a summary of the results.

What it does

Where it runs

How it works

Logic overview

1. Form submission

The workflow begins with a form titled Update Item Record with Excel.

Required inputs:

The form description specifies that the CSV should contain:

2. Pre-processing and confirmation

The workflow reads the uploaded CSV and counts non-blank lines, subtracting the header row to calculate the number of barcodes. It then shows a review screen telling the user how many barcodes were detected and that the selected item records will be updated in Alma.

This is a confirmation step only. It does not validate the CSV headers beyond assuming the first row is a header row.

3. Extract CSV rows

A separate branch extracts the CSV contents into rows for processing. This branch is merged back after the user confirms submission.

4. Route to the selected Institution Zone

After confirmation, the workflow uses the selected Institution Zone value to route API calls through the Alma Network node to the correct institution.

5. Retrieve each item by barcode

For each CSV row, the workflow retrieves the Alma item record using the barcode in that row.

6. Build the update payload

The workflow combines the spreadsheet row with the retrieved Alma item record, then updates these Alma item fields from the spreadsheet columns:

Important behavior:

This means the workflow is not just adding values; it can also clear existing Description / Enum / Chron values.

7. Update Alma item records

The workflow sends the modified item record back to Alma using the item update endpoint.

8. Summarize results and email the user

After all item updates complete, the workflow counts:

It then emails the submitting user a summary report.

If results exist
If no results

Artifacts produced

UDC Barcode Update Form

At a glance

· Status: Active
· Environment / Tags: Community Use Case
· Applies consortium-wide?: No
· Runs on: UDC Institution Zone (01WRLC_DOC)
· Trigger: Staff submit a LibOW form called Update Barcode
· Primary outcome: Helps staff update an item barcode only when the item is committed to retain; otherwise, it sends the item to Cataloging for review.
· Who receives results: The staff member using the form receives an on-screen success, routing, or error message.

Why this exists

This workflow gives staff a quick form-based way to update an item barcode in Alma while protecting retained materials from accidental mishandling. It checks the item’s retention status before allowing a barcode update, and it routes items that are not marked for retention to Cataloging instead of updating them directly.

What it does

· A staff member opens the Update Barcode form and enters or scans the item’s current barcode.
· The workflow runs against the UDC Alma IZ.
· It retrieves the Alma item record using the submitted barcode.
· If Alma cannot find or retrieve the item, the staff member receives an error message and can restart the form.
· The workflow checks whether the item is marked Committed to Retain.
· If the item is committed to retain, the form displays item details and asks the staff member to enter the new barcode.
· The workflow updates the Alma item record with the new barcode.
· After the update, it scans the item in at the configured UDC circulation desk.
· If the update fails, the staff member receives an error message and can restart the form.
· If the item is not committed to retain, the workflow adds a work order and tells the staff member to send the item to Cataloging.

Where it runs

· Alma IZ(s): 01WRLC_DOC
· Systems touched:
· n8n forms
· Alma APIs
· Alma Network configuration
· Reports / queries used: None
· Credentials referenced:
· NZ Production - Alma APIs - Read & Write
· NZ Sandbox - Alma APIs - Read & Write

 

How it works

Logic overview

· Start: The workflow begins when a staff member submits the Update Barcode form with the item’s current barcode.
· Institution context: The Alma Network node is configured for 01WRLC_DOC, rather than all network members.
· Retrieve item: The workflow uses the submitted barcode to retrieve the Alma item record.
· If item retrieval fails: The workflow displays an error message with Alma’s returned error text.
· If item is committed to retain: The workflow displays item details, including title, author, publication date, location, temporary location, retention status, retention reason, and retention note. The staff member then enters a new barcode.
· Update item: The workflow copies the existing item record, replaces the barcode value with the new barcode, and sends the updated item record back to Alma.
· If barcode update succeeds: The workflow scans the item in at library DCVN and circulation desk DEFAULT_CIRC_DESK, then displays a success message confirming the new barcode.
· If barcode update fails: The workflow displays an error message with Alma’s returned error text.
· If item is not committed to retain: The workflow adds a work order for library DCVN, department TECH, work order type AcqWorkOrder, status Physical Processing, and tells the staff member to send the item to Cataloging.

 
Artifacts produced

None. The workflow does not create files, reports, spreadsheets, or email notifications. It produces on-screen form completion messages only.