ReCAP Shared Collection - Alma coding for items and holdings

General information

Prospective acquisitions

• Collaborative collection development agreements - these are with specific vendors and coding is handled via Alma Import Profiles maintained by ITS

• Isolated items or sets of items

  • If selectors wish to add specific new acquisitions to the ReCAP Shared Collection (at either HD or RD), the holding and item coding should be applied manually in Alma AT LEAST TWO DAYS BEFORE THE ITEM PHYSICALLY ARRIVES AT OFFSITE STORAGE.

  • This will ensure that the item record is ingested into SCSB such that is can be requested by ReCAP partners. 

• Replacements

  • Staff may have to manually code (or uncode) holdings and items for exceptional processes such as when items are damaged. See ReCAP Shared Collection - Policies and Workflows for Living Collections Exception Processing

What to do if items were already accessioned at HD/RD but were not committed at the time of accessioning and need to be committed now

• Apply the Alma coding for holdings and items

• Send an email to HTC (the SCSB vendor)(scsb-notifications @ HTCinc.com) with a list of barcodes and ask them to add the barcodes to SCSB

Private items at ReCAP facility

• For items stored at ReCAP that are private (not shared with partners), there will be no 583, Item statistic or item provenance field. 

Retrospective work done in 2018

• When Harvard joined ReCAP in 2018, Alma holding and item coding was applied through batch processes. Details at Shared Print Retention Notes - 2018 project

Holding fixed field 008, and 583 Action Note (commitment information)

Alma Item fields 

• The retention checkmark should be set to Yes. This will prevent the item from being withdrawn from Alma. 

• The Retention Reason field should be populated with the appropriate value (e.g. ReCAP, or HathiTrust / ReCAP). 

Open

SCSB use restrictions

These are applied automatically based on Alma item policy at the time of accession.

Moving holdings and items

• If an item moves to a new holding ID and bib ID (as in the case of a serial title change), it will not affect the item request process, but it will mean that metadata updates for that item record can no longer be sent via our weekly Submit Collections process, which updates bib data in SCSB. When/if our partners ingest our data into their discovery systems, the bib will reflect the old metadata.

• Due to the overhead of keeping holding/item IDs in sync, we do not attempt to correct the data in SCSB if items move in Alma.

• If it is necessary to update SCSB for a specific bib, such that metadata updates from Alma will ingested into SCSB, this can be done via API. Content LTS.

Policy for on-going accessions of serials and multi-volume works

(Authored by TSWG and added June 2023, updated Sept 2025)

Policy

• New receipts on offsite holdings (RD, HD) & the 583 note

  • Staff do not need to edit the 583 field to reflect specific volumes, e.g. do not add $3.

  • If there is no 583, do not add one unless you have specific instructions to do so for a given title

  • When duplicating or predicting serial/multi-volume items, staff do NOT need to review the new item’s retention markings. It is okay to leave the retention markings the same as the duplicated item.

• If all prior receipts have been transferred to RD, create a new holding for new receipts reflecting the location of past items prior to transfer

  • If you need to retain the serial patterns, you may wish to duplicate the RD/HD holding -- be sure to remove enum/chron holdings on the new holding

  • Review the Version History of the RD/HD holding to determine the previous shelving location, and use that for the new holding

  • Do not add field 583

  • The POL should be on the holding for the new receipts 

Ramifications of policy

• There will be no review of commitment status for new items for serials and multi-volumes, where some items were already committed. For example, if v.4 was committed as part of the 2018 scope of material, and staff duplicate that item when v.5 arrives later, then v.5 will be committed to retain as well, even though it was not explicitly reviewed for retention and was not part of the original scope of material for ReCAP sharing.

Background and rationale

• For serials and multi-volumes (MVMs), there are cases where some items for a given title were committed to the Shared Collection in 2018, and others weren't. Items received for these titles since 2018 may or may not have the same commitment status as previously received items.

• The most efficient workflow for staff is to not attempt to code/un-code retention commitments when duplicating items that are created for new issues/volumes of serials or MVMs.  Requiring staff to verify retention coding for new receipts increases processing time for new receipts.

• The ramifications of duplicating retention commitments for newly received items are relatively small, and the need for efficient processing outweighs the need for explicit review of new commitments.

• If staff were required to review each new item's retention status / coding , then the workflows involving item duplication would be considerably longer and have an adverse effect on efficiency. Below is an example workflow that staff would have to follow if the policy were to review item retention of duplicated items:

  1. Serial X has some items at HD committed to ReCAP, and other items not committed.

  2. A new volume for serial X arrives in tech services, and staff bring up the list of items in Alma.

  3. Staff duplicate an item and update the Enun/Chrom/Description and Receiving Date.

  4. At this point in the process, staff do not know if there are any commitment statements because these fields do not display on the List of Items screen. If staff are asked to make sure new items do not have retention coding, then at this point they have to scroll down the screen and review retention coding for every single item they create. If retention commitment statements are present, they have to edit 3 additional fields.

  5. Staff send the volume to end-processing.