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.

  • No labels


  1. For the "Loading shelfready cataloging records" use case, Duke has Shelf-Ready plans with GOBI that both utilize the OCLC WCP records and divide into a firm order and an approval workflow. The firm order workflow looks like the use case described above; however the approval workflow does not work off a pre-order record. Our approval shelfready workflow generates a new bib, holding, order and item with the full barcode populated. 

    Should I add this as a use case, or do you think it's more-or-less covered in the one above?


  2. Hi Leeda, is that the same as the "loading approval cataloging records" scenario (the last one listed currently)? If yes, then just add some notes or updates to that scenario.

    I didn't create all the scenarios that I could think of (DDA, EBA, loading various cataloging files, loading authorities), hoping that others would start filling those in. So hopefully everyone will have at it!

  3. Thanks Ann-Marie! I think your note for "loading approval cataloging records" covers it. Another question: for "Record Source," do we need to add more use cases for other approval vendors (Casalini, Amalivre, Harrassowitz) if the case is basically covered above, or can we just add the vendors into the Record Source for the existing cases? 

    I'm going to try to tackle a use case for Serials Solutions 360Marc update loading today, with the caveat that it may be a confusing bear. (I only learned how to load them myself late last year.)

    1. Hi Leeda - I missed this earlier question. If it's the same workflow, but records come from a different source, just add the additional source(s) into the existing case. That will help us get a feel for how widespread that workflow is, and how many sources are already attuned to it. Thank you!

  4. Leeda: Do Iberoamericana and Retta provide EDIFACT records along with the MARC for your approvals? We do not receive an EDIFACT invoice with our approvals, so the approval workflow that requires the invoice to be loaded separately would not work for us. 

  5. Hi Christie, they do not supply EDIFACT for us; in fact, none of our monograph loads have EDIFACT at the moment. They all come in with order and invoice data in the 9xx fields. Should we parse these out as a new use case? For now I will add a note to the existing use case, that everything applies except the EDIFACT part.

  6. Thanks, Leeda. I added a new use case just to capture it even if it is out of scope for v1. 

    Ann-Marie: Should we add workflows for electronic resources and assume that the electronic holdings data will be represented within the holdings? I don't know if it has yet been decided where local electronic holdings will be stored.

    1. Same question here about electronic resources and holdings.

      1. Hi Lisa and Christie, Sorry - just surfacing for air from nonstop meetings today. Yes, please add those as use cases. If you think that there may be related ERM updates, be sure to add a note about that. Speaking of which, we should talk for a minute tomorrow about whether we have any ERM subgroup members in our group, or if we need to solicit someone from ERM to join this group. Would be good to have a person who can connect us to the latest thinking on that portion of FOLIO.

        1. I see Kristin Martin's name on the group members page...

  7. Cornell only uses EDIFACT for invoice data both firm and continuations. The vendors are Coutts, Yankee, Amalivre, Casalini, Harrassowitz, Hein, and Midwest.

  8. Thanks, Gary - I've added Hein and Midwest to our list of sources for batch data.

  9. Loading User data is a common use case also. A large number of our University Libraries uses a process in which patrons enter their data via a web form. This data is converted into the format of the library system in the background and then imported into the library system on a daily/hourly/minutely basis. Entering user data at the service point is not an option for these libraries.