Data Import Subgroup: Use Cases

Subgroup members: please add any relevant use cases. If a use case is already represented, add any additional details (your name, record source, other notes) to the existing case instead of creating a new case. 

Note: Assume any files in the Use Case are MARC unless otherwise specified

Use case (brief)Use case descriptionFile sourceFOLIO components affectedFunctional Area(s)Submitted byNotes
1Loading pre-order recordsUser prepares bib and pre-order data in vendor system; load to FOLIO to create bib & order, then finalize order and send from FOLIO to vendor


MARCcat, Instance, Holdings, Item, OrderAcquisitionsMay match to an existing bib record or create a new bib record. May need to create different FOLIO components depending on P or E (e.g. items)
2Loading order recordsUser orders in vendor system, then loads to FOLIO to create bib and orderGOBI, OCLC, PQ-OASIS, OttoEds, Casalini, Amalivre, ATC, (Cornell has local system POOF which loads order records pulled from OCLC via Search API)MARCcat, Instance, Holdings, Item, OrderAcquisitionsMay match to an existing bib record or create a new bib record. May need to create different FOLIO components depending on P or E (e.g. items)
3Loading shelfready cataloging records from acq vendorUser receives shelfready services from vendor; loads to FOLIO to overlay any previous bib record, update holding with final location/call number/other info, update item record with barcode/piece/other infoGOBI, OCLC, Casalini, HRSW, Amalivre, Proquest/Coutts, CNPIEC, Qingyinkemao Development CenterMARCcat, Instance, Holdings, ItemCatalogingKey piece of this is matching to any pre-existing bib, holdings, item
4Loading approval cataloging records, separate EDIFACT invoiceUser receives records for incoming approval plan purchases (P or E); loads to FOLIO to create bib, holdings, item, order; followed by separate EDIFACT invoice load

GOBI, OCLC, Casalini, Amalivre, Harrassowitz

MARCcat, Instance, Holdings, Item, Order, Invoice



May match to an existing bib record or create a new bib record; may have full shelfready data or may require manual updating by library staff to finalize everything


Loading eresource catalog records from a knowledge base MARC record service

User receives files of new, update and delete records to manage discovery of electronic resources. Loads to FOLIO to create, update or delete bib records.ExLibris, EBSCO, OCLC, ProQuest, Oxford, Project MUSE, Swank, Kanopy, Cambridge

MARCcat, Instance,

Codex?, ERM?


Each file is split between monographs and serials to streamline processing and troubleshooting. Currently matches on vendor-supplied system number. Match file is further subdivided by the ILS between records with temporary vendor system numbers and stable vendor system numbers. (More details available)

Codex situation: may have a version coming from Inventory and from External KB

Lisa McColl - We use provider neutral records. If we receive two "copies" of ebooks that are from two different platforms, we currently need the system to match on OCLC number (although I realize other institutions that have provider neutral records choose other match points such as ISBN), then either 1) add the new ebook to the existing record if there is one, both updating the bib with an added 856 field and adding an holdings to that existing bib or 2) create a new instance/holding for this new ebook.

6Loading outsourced cataloging records (contract cataloging)User receives a file from a vendor of fully-cataloged non-Latin script records to overlay brief bib records, and update holding records. Source of bib record is not the acquisitions vendor.Wuheba, Backstage, DK Agencies, Panmun, CIBTC, LeilaMARCcat, Instance, Holdings, ItemCatalogingWhen initial file is sent to the vendor it includes item barcode information for each title. The completed vendor cataloging file then uses the barcode recorded in a MARC field as the match point. Holding records are either created or updated with final call number, which also update the item record. May just bring in bib record and do the rest (holdings, items) locally.
7(re)Loading bibliographic records that have been exported from the system, and edited - updating bib data only.User may need to perform a batch cleanup on a set of bibliographic records for many reasons. Examples could be adding a consistent note to a set of identified records so the records display in a certain way in the discovery layer or making a set of records RDA compliant.FOLIOMARCcat, InstanceCataloging(In scope?) - Sometimes it is necessary to update the bibliographic portion of the records only, without touching the holdings and items attached to them. This could be seen also as a "Global Edit" issue, in addition to an import issue or even instead of. That depends on the scope of this loader. Match points would probably best be the FOLIO ids in this case. Batch editing/global updates in FOLIO might help keep from having to export records.
8(re)Loading bibliographic, holdings, items records that have been editedUser receives a notice that the URLs for a particular set of eresources have changed. Those eresource need to be identified, exported, then reimported with the correct URL that is placed in the bibliographic record but also on the holding record (presumably not the item record, but I'm not sure)FOLIOMARCcat, Instance, Holding, ItemCatalogingUnlike the above scenario, in this one, multiple parts of a record will need updating. Match points would probably best be the FOLIO ids in this case. Again, whether or not this is in scope depends on the ability of MarcCat to perform a global edit and send the changes to the Inventory app, without needing to export at all.
9Loading approval cataloging records, plus MARC invoicingUser receives a file of cataloging records with order and invoice data in 9xx fields. Import process creates instance, holdings, items, order, and invoice. All happens at point of receipt.

Bach, Books from Mexico, Eastview, Erasmus, Iberoamericana, Karno, Retta, Weinberg, Worldwide, Amalivre, Rossi, Iturriaga, (JPT), MIPP, Lexicon, Leila

(EDI available from Casalini, Harrassowitz, GOBI)

MARCcat, Instance, Holdings, Item, Order, Invoice



Unlike the approval scenario that describes the ingest of an EDIFACT invoice after processing the MARC order; these are approval records for which we only receive invoice data in MARC 9xx fields. We do use the same process for other vendors as well, but I have excluded vendors from the list if we are able to receive EDIFACT invoices. Our current process is actually two processes; the invoice import process immediately follows the order import process. (scheduled once, then calls the order process, then invoice process). It would be preferable if a single process could create the order and the invoice. Duke runs one invoice at a time, a macro process.
10Loading non-Latin firm cataloging records with MARC invoicingUser receives a file of fully cataloged records with non-Latin script and with invoice data in 9xx fields. Import process updates instance, holdings, item, and invoice.CIBTC, LeilaMARCcat, Instance, Holdings, Item, Invoice



This is similar to the "Loading outsourced cataloging records" scenario with the addition of invoice data in the 9xx field. Point of order: creating orders locally manually or spreadsheet (no vendor records). At point of receipt, these records are full cataloging (to overlay brief record), plus 9xx invoicing data.
11Loading catalog records for physical materials with no ordersUser receives a file of records and loads to FOLIO to create bibs, holdings, and itemsLC-Cairo (PL-480) plan, MARCIVE, (and many other vendors for Cornell)MARCcat, Instance, Holdings, ItemsCatalogingThese types of loads do not need order or invoice generation. No interaction with acquisitions. For physical materials. Similar to approvals without interacting with acquisitions.
12Loading catalog records for e-resources with no ordersUser receives a file of records and loads to FOLIO to create bibs, holdingsLots of e-vendorsMARCcat, Instance, HoldingsCatalogingThese types of loads do not need order or invoice generation. No interaction with acquisitions. For e-materials. Similar to approvals without interacting with acquisitions.
13Loading catalog records with no ordersUser receives a file of records and load to FOLIO to create bibsCRL (shared collection)MARCcat, InstanceCatalogingThese types of load do not need order or invoice generation. Uses 852 in the bib to point users to the ILL form. Also use this for lots of e-resource files, with URL in 856. Holdings not mandatory in FOLIO inventory.
14Single record import/overlayUser in cataloging department needs to overlay a brief record that may have come in via acquisitions with a fully fleshed out record.OCLC, Z39.50MARCcat, Instance, Holdings, ItemCataloging

(In scope?) While this defies the word "batch" I wanted to put something here, even if it's a placeholder, to make the ability to import a single record in a simple way, does not get overlooked. Currently in OLE our single record import is so clunky that everyone uses the "batch import" even for single records, because it is easier to use than the "single bib import" feature in OLE. In our system, previous to OLE, users had the ability to overlay a record that was open in the ILS without having to force a match point. The overlay was made just by virtue of the fact the record they wanted to overlay was open. This feature has been sorely missed by staff members. Without out it this once simple process has become exponentially complicated to staff members.

15Loading items to a single holding recordUser takes a spreadsheet of item information and loads to a single holding record in FOLIO to batch create itemsSpreadsheetHolding, ItemsCatalogingUsed for special collections projects and large holdings management projects. Large donor projects. Link to the holdings, plus a way to create the items from the spreadsheet data. Might need to match on the bib first? Would be best if could match to the actual holdings ID though.
16Performing batch authority control updates to catalog recordsExtracts from the catalog are sent to an authority control vendor. Vendor returns a file of updated bib records; user loads into FOLIO to overlay existing bib records



MARCcat, InstanceCatalogingExtracts and returned update files can run weekly or quarterly, or both.
17Loading authority recordsAuthority control vendor provides new, changed, (and deleted?) authority records, based on catalog data sent by the library. Library loads the authority records to FOLIO to inform the authorized headings and cross-references





Do we know how much or how little Inventory and Codex will be paying attention to authorized headings and cross references?

18Load single authority recordSearch from FOLIO to find authority record and import.VIAF, OCLC, other sourcesMARCcatAuthorities
19DDA Discovery Records/PDAVendor provides DDA Discovery records. Import creates a new instance with a local electronic holdings record.GOBI, Kanopy, Coutts-OASIS, eBook Central

MARCcat, Electronic Holdings (Local - Inventory)

Unless only loading to Discovery

CatalogingThe instance receives an Instance Status of DDA Discovery to differentiate the record from that of an instance with owned items. Discovery records may be loaded into discovery only (outside the scope of FOLIO) or into FOLIO. Often a code so that the library knows these are not owned (yet)
20DDA Purchase (POP)/PDAVendor provides a MARC file with order and invoice data in 9xx fields. Import replaces DDA Discovery record and updates local electronic holdings record.GOBI, KanopyMARCcat, Electronic Holdings (Local - Inventory), Order, Invoice



The Instance Status is changed from DDA Discovery. If Discovery records are loaded into discovery system only (not ILS), then POP records are new to FOLIO. If Discovery records are loaded to FOLIO, then POP records have to overlay/update the discovery records, plus take care of the acq stuff.
21EBA DIscoveryPublisher provides EBA Discovery records. Import creates a new instance with a local electronic holdings record.Cambridge, Docuseek2 (streaming video), Taylor & Francis, Project MUSE, Oxford Scholarship Online, Sage, JSTOR

MARCcat, eHoldings (Local Inventory)

Unless only loading to discovery

AcquisitionsMay extract the ISBNs from the publisher records to harvest better OCLC records. Code to brand these records, so that they can be removed or suppressed. (Note: EBA not working so well for Lehigh/Cornell)
22EBA POPAt end of a cycle, library decides which titles will be purchased and which will be dropped.CambridgeMARCcat, Electronic Holdings (Local - Inventory), Order, Invoice



Would need to change the flag and do the acq work

Orders from spreadsheets

Bibliographer provides bibliographic and order data in spreadsheet. Import creates a new instance, holdings, item, and order.

local spreadsheet

Andromeda Research, Zahraei, Sulaiman, Nazeer, MG Noura, Libra, Lexicon, Kozmenko, Panmun, Iran Farhang

MARCcat, Instance, Holdings, Item, OrderAcquisitions

Bibliographer enters data for orders into a spreadsheet or uses spreadsheet provided by vendor. Staff uses MarcEdit to convert the spreadsheet to a brief MARC record with order data in the 9xx fields. Some vendors for which we create orders in this manner include: Andromeda Research, Zahraei, Sulaiman, Nazeer, MG Noura, Libra, Lexicon, Kozmenko, Panmun, Iran Farhang. (Cornell does this for Korean and Vietnamese books, but do not create order records - just pay on a dummy record.) This workflow is also of interest to Duke. Maybe add OCLC numbers, so that you have a matchpoint for the cat record. MIght just want to create Instance, and then create MARC later. Others may want to create both Instance and MARCcat. If only creating Inventory, maybe just creates Inventory JSON. If loading to MARCcat, create MARC version too.

24Invoice records from EDI fileEDI file is automatically imported into system.



GOBI, Coutts, Nardecchia, Casalini, Hein

InvoiceAcquisitionsUser links invoice (scanned image) to order. Match point is a single number representing title/account#/sub-account#.
25Load MARC file to create Inventory instance, but don't store a MARC record in FOLIOMaybe at point of order - I want an inventory instance and order, but no MARC record. Then at point of receipt, I'll load or create a MARC cataloging record and link it up to the pre-existing Inventory instance.???Instance, Order


Would start to break the "tyranny of MARC." Have to be mindful of what is being exported to patron discovery layer, and from where within FOLIO. Maybe a time-saver for spreadsheet workflow, if can just create a brief Inventory JSON record and not have to deal with MARC details.
26Load bib and order data via API (XML format)Real-time load to create bib and orderGOBI, Coutts, HRSWInstance, maybe MARCcat, Holdings, maybe Item, OrderAcquisitions
Chicago already has this with OLE; also used by Alma, Sierra, Koha libraries
27Load records for print and e-resources that are conglomerates of OCLC records, vendor records, and local information.Vendors supply records that are often substandard in quality to what is available through OCLC. We take what we need from the vendor records: the indication that we now have access to this resources via an identifier for that resource, and in the case of eresources, our institution specific URLs, locate appropriate OCLC records (using OpenRefine and OCLC's API), merge the records, keeping most of the OCLC information, but also adding the institution specific URL, then run a MarcEdit macro to add local information such as collection codes that relate to our CORAL. This is all done at a pre-import stage at the moment. Mostly MARC files, but sometimes spreadsheets.




Instance, MARCcat, Holdings, maybe ItemCataloging

Since we currently do this before the point of import, I would not expect this from v.1 of FOLIO, I don't think. However, I think if a system gave the user the ability to construct records in a staging area, giving the user the ability to select what they want to take from various record sources, including local fields, it would the steps listed in the description area. Relates to "beefing up" smaller vendor records with TOC, local format info, by merging OCLC data with vendor records. Mostly just keep the URL and ISBN from the vendor record, hopefully an OCLC number. Track in CORAL, with CORAL IDs.

In an ideal world we would all use the same record from one source, but there is a lot in place preventing libraries from achieving that ideal, so this system of constructing records from various sources is what we need to do to try to have important information like the Table of Contents, 33X fields, 006 and 007 fields appropriately coded, included in the record.

28(re)Loading bibliographic records that have been exported from the system, and edited - updating OCLC number only.User may need send out records to match to OCLC, then reload to FOLIO to update the OCLC number. That may be the only piece of data that they want to update in the FOLIO MARC record and Instance. FOLIOMARCcat, InstanceCataloging



May only need to import a delimited file with FOLIO HRID and OCLC number.