Question 7: Pink "toast" messages when importing/overlaying
What do the various pink or red messages I see after importing or overlaying a record mean? And what should I do about them?
Answer:
These messages are supposed to quickly confirm that an action was successful or alert you to an error. But they are not always reliable.
If you get a green "toast" you can safely assume your record imported/overlaid correctly. If you get a yellow toast saying your process might take a while, you can assume it is working but need to check back later.
A pink or red toast is supposed to mean the action failed, but if you get this particular pink toast:
... it is likely your import or overlay was actually successful.
This is partly a performance issue, and partly an example of the need for better error messaging. It seems to happen when FOLIO does not have enough memory available.
If it helps, you can think of it as FOLIO being overwhelmed and saying "I don't know." The best course of action is to refresh your browser and/or wait.
We may need to batch our cataloging work until this has improved.
Generally, you should wait at least a few hours and check again before assuming an action, especially an import, failed. If you try to re-import the record, you will likely create a duplicate.
*By the way, these are apparently called "toasts" because they pop up like toast from a toaster.
Question 6: Reviewing own work in FOLIO
How can I review my own work in FOLIO Inventory?
Answer:
We can search based on the “transaction data” notes, provided we limit in advance by a date range. (Without this limit, the search will usually time out.)
In Inventory, in the Instances search segment (the default), start by limiting the search by “Date updated.” Enter dates, in the format YYYY-MM-DD, in both Form and To fields, even if you are looking for records updated on a single day. Select “apply.”
Then select “Query search” from the dropdown menu.
Enter this search: holdingsRecords.notes=“userid:netid” (replacing netid with your netid)
Note that this query will retrieve records with your netid in the transaction data note that were updated on or between specific dates, but they may not have been updated *by you* on that date.
In the near future, we should be able to better refine this search.
Question 5: Search fails for a known item
Sometimes I search in Inventory for a known item, for example, an instance hrid or item barcode, and the search fails. Why is this happening?
Answer:
It's likely either your search (in the case of hrids) or the field itself (in the case of barcodes) has an extra trailing or leading space.
FOLIO currently stores and searches very literally, including spaces and carriage returns. (This will be fixed in future release.)
Look at your search carefully – it's surprisingly easy to enter an unintentional space before or after your search term.
If this doesn't help, try searching another way for the record. If you can find it another way, examine the field you were searching for initially. Look for extra spaces or even extra carriage returns before or after the data.
Question 4: Instance record won't save when updated
A number of us have been encountering instance records recently that won’t save when the instance status (and cataloged date) are updated. What should we do when this happens?
Answer:
Scroll through the rest of the instance record and look for a pink field/red text as illustrated below. This is happening, basically, when there is data in the MARC bib that Inventory thinks it should recognize but it doesn’t know what to do with it. (More technically, this happens when a field that is mapped to the instance contains only subfields that are not mapped.) This is usually happening with 948 fields.
Once you’ve identified the problematic field, close the instance without saving, and edit the underlying record in quickMARC to update that field. In the case of the 948, if there is a $z, change it to a $a. (But don't change the data, just the subfield.)
You should now be able to edit the instance data.
Question 3: Creating multiple item records
Creating multiple item records (for a multi-volume publication, for example) is a lot of work. Is there a way to make it easier?
Answer:
You can use the "duplicate" action (from the Actions menu). You'll only need to add a new barcode and update the enumeration/chronology.
Question 2: Changing instance status
Should the instance status/cataloged date be updated for materials that we cataloged in Voyager if we are making updates to the record? What about added copies or added volumes – what should the instance status/cataloged date be for these?
Answer:
The instance status “cataloged” along with the appropriate cataloged date should be added/updated when a title is first cataloged. Since this differs from our practices in Voyager, migrated records that were already cataloged will not have either field populated. There is no need to change this, as our holdings should already have been set in OCLC and these materials do not need to be identified as new in the catalog. The same is true for added volumes and added copies as well as routine bibliographic maintenance.
If this bothers you and you do choose to add instance status/cataloged date retro-actively, be sure to add the date the title was actually cataloged, not today’s date!
Question 1: Edits using quickMARC
Should we be removing any fields, using quickMARC, after importing records from OCLC?
Examples include
948 “No holdings in COO”
035 OCLC number duplicated with alpha prefix (e.g. (OCoLC)onXXXXXX)
6xx – any non-English language, non-FAST headings
Answer:
While it won’t hurt to “clean up” records, it is time consuming and unnecessary use of quickMARC increases the likelihood of introducing unintentional errors. At some point in the future we will likely have either more refined import settings or some programmatic (batch) operations that will either keep these stray fields from coming in to our database or remove them periodically. So I recommend not routinely using quickMARC for any routine cataloging of print materials.