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 description | File source | FOLIO components affected | Functional Area(s) | Submitted by | Notes |
|---|---|---|---|---|---|---|
| Loading pre-order records | User 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 | GOBI, PQ-OASIS, OCLC | MARCcat, Instance, Holdings, Item, Order | Acquisitions | May 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) | |
| Loading order records | User orders in vendor system, then loads to FOLIO to create bib and order | GOBI, OCLC, PQ-OASIS, OttoEds, Casalini, Amalivre, ATC | MARCcat, Instance, Holdings, Item, Order | Acquisitions | May 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) | |
| Loading shelfready cataloging records from acq vendor | User 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 info | GOBI, OCLC, Casalini, HRSW, Amalivre | MARCcat, Instance, Holdings, Item | Cataloging | Key piece of this is matching to any pre-existing bib, holdings, item | |
| Loading approval cataloging records | User 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 or MARC invoicing | GOBI, OCLC, Casalini, Amalivre, Harrassowitz, Iberamericana, E. Iturriaga, Retta Libros, MIPP, Lexicon, Leila | MARCcat, Instance, Holdings, Item, Order, Invoice? | Acquisitions Cataloging | 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 Duke has an Arabic script load in this use case. Also, we currently do not run EDIFACT loads with these plans; order and invoice data appear in the 9xx fields. | |
Loading eresource catalog records from a knowledgebase 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? | Cataloging | 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. | |
| Loading 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, Leila | MARCcat, Instance, Holdings, Item | Cataloging | When 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. | |
| (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. | FOLIO | MARCcat, Instance | Cataloging | Lisa McColl McColl | (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. |
| (re)Loading bibliographic, holdings, items records that have been edited | User 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) | FOLIO | MARCcat, Instance, Holding, Item | Cataloging | Lisa McColl McColl | Unlike 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. |
| Loading approval cataloging records | User receives a file of cataloging records with order and invoice data in 9xx fields. Import process creates instance, holdings, items, order, and invoice. | Bach, Books from Mexico, Eastview, Erasmus, Iberoamericana, Karno, Retta, Weinberg, Worldwide, Amalivre, Casalini, Harrassowitz | MARCcat, Instance, Holdings, Item, Order, Invoice | Acquisitions Cataloging | (In scope?) - 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. It would be preferable if a single process could create the order and the invoice. | |
| Loading firm cataloging records with invoice | User 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, Leila | MARCcat, Instance, Holdings, Item, Invoice | Axquisitions Cataloging | (In scope?) This is similar to the "Loading outsourced cataloging records" scenario with the addition of invoice data in the 9xx field. | |
| Loading catalog records with no orders | User receives a file of records and loads to FOLIO to create bibs, holdings, and items | LC-Cairo (PL-480) plan, MARCIVE | MARCcat, Instance, Holdings, Items | Cataloging | These types of loads do not need order or invoice generation. | |
| Loading catalog records with no orders | User receives a file of records and load to FOLIO to create bibs | CRL | MARCcat, Instance? | Cataloging | These types of load do not need order or invoice generation. | |
| Single record import/overlay | User in cataloging department needs to overlay a brief record that may have come in via acquisitions with a fully fleshed out record. | OCLC | MarcCat, Instance, Holdings, Item | Cataloging | Lisa McColl McColl | (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. |
| Loading items to a single holding record | User takes a spreadsheet of item information and loads to a single holding record in FOLIO to batch create items | spreadsheet | MARCcat, Instance, Holding, items | Cataloging | Used for special collections projects and large holdings management projects. | |
| Performing batch authority control updates to catalog records | Extracts 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 | LTI Backstage | MARCcat, Instance? | Cataloging | Extracts and returned update files can run weekly or quarterly, or both. | |
| Loading authority records | Authority 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 | LTI Backstage | MARCcat, Inventory? | Authorities | Do we know how much or how little Inventory and Codex will be paying attention to authorized headings and cross references? | |
| DDA Discovery Records | Vendor provides DDA Discovery records. Import creates a new instance with a local electronic holdings record. | GOBI | MARCcat, Electronic Holdings (Local - Inventory) | Cataloging | The instance receives an Instance Status of DDA Discovery to differentiate the record from that of an instance with owned items. | |
| DDA Purchase | Vendor provides a MARC file with order and invoice data in 9xx fields. Import replaces DDA Discovery record and updates local electronic holdings record. | GOBI | MARCcat, Electronic Holdings (Local - Inventory), order, invoice | Acquisitions | The Instance Status is changed from DDA Discovery. | |
| Orders from spreadsheets | Bibliographer provides bibliographic and order data in spreadsheet. Import creates a new instance, holdings, item, and order. | local spreadsheet | MARCcat, Instance, Holdings, Item, Order | Acquisitions | 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 | |
| Invoice records from EDI file | EDI file is automatically imported into system. | EBSCO | Order | Acquisitions | User links invoice (scanned image) to order. Match point is a single number representing title/account#/sub-account#. | |
| Load MARC file to create Inventory instance, but don't store a MARC record in FOLIO | Maybe 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, maybe Order | Inventory maybe Acq | 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. |