...
| Date Entered | Contact Person | Impact Statement | Jira Issue | Is this a feature that hasn't been developed yet and doesn't have a Jira issue? | How old is the Jira issue? If there is no Jira issue, was this ever discussed in MM SIG? If yes, when? | What operations are impacted in your library? | Is this critical to your library operations? | Other Libraries that Have Similar Impact | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2023-05-04 | We often don't understand the logs because either there isn't enough information or no information. Hence we have to go to our hosting vendor to get information | Multiple issues,
| The logs have been a problem since Data Import was first released | technical services, access services, discovery | Yes. When we are unable to resolve the issue, it can take several weeks for our hosting vendor to resolve the issue. This means that those resources don't get to the patron. | Wellesley College | ||||||||||||||||||||||||||
| 2023-05-12 | The lack of integrated call number printing in Folio was an unanticipated issue when we migrated. Alternative solutions require third-party software on a self-hosted server or a vendor service. These alternatives require the library shoulder an additional unexpected cost. |
| November 2018 ; it is a go live requirement by all libraries adopting Folio | technical services | Yes. This has budget implications for operating expenses. | |||||||||||||||||||||||||||
| 2023-05-12 | MARC to MARC matching in Data Import jobs is not robust enough to suit our needs. It needs to be able to deal with repeatable fields and subfields. MARC to Instance matching to then act on the SRS MARC record is not possible. |
| 2020 | technical services, access services, discovery | Yes. | Cornell University 5 Colleges | ||||||||||||||||||||||||||
| 2023-5-12 | Publication date is not a searchable or filterable field. API queries are complicated by mapping from 260/264$c, which can include text preceding the year, especially in archival or special collections materials. This issue extends to our catalog, which includes UI for searching/filtering by publication year but is non-functional. |
| 2019 | technical services, access services, discovery | Yes. This has particular impact on Special Collections and Archives staff. | GBV and other institutions and library networks have identified this as a gap as well 5 Colleges | ||||||||||||||||||||||||||
| 2023-05-12 | We are feeling the lack of ability to overlay records directly from an OCLC Connexion client push. This is a common workflow that has been completely disrupted by the inability of Folio to take that data and match it to records in its database. Not being able to make edits in the OCLC Connexion client and then pushing the changes over to Folio has negatively impacted our efficiency in cataloging materials as we have to search for the record in Folio and OCLC, make sure it's the correct record, overlay the record via the Inventory UI, and then make manual edits using quickMARC. Often, these manual edits could be easily automated using Connexion's tools. |
| 2021 | technical services | Yes. Impacts on cataloging staff efficiency. | 5 Colleges Middle TN State University | ||||||||||||||||||||||||||
| 2023-05-12 | With single record import/overlay and any bib record to create instances, the process creates sometimes multiple MARC fields 035 for the OCLC record. When we migrated, we removed the 2-3 letter indexing prefix to our OCLC number. Since we went live we know have multiple OCLC numbers in our records with different structures (some with and some without prefix). The issue is the integration with WorldCat where in the WorldCat registry you have to pick only 1 option for how OCLC numbers are formatted in your LSP. We have selected without prefixes - however, this will work pretty much only for our migrated bib records. This affects users who are looking for our materials and just creates junk data that we can't really clean up. | This hasn't been addressed. | Discovery, circulation, ILL, cataloging, integration with WorldCat | yes | Wellesley College | |||||||||||||||||||||||||||
| 2023-05-12 | Inability to import all of our eResource metadata title sets. We have to pay in order to batch load sets into discovery because the functionality we need isn't in FOLIO. We need to be able to handle large create and update import functions, large number of records to be created or updated, and the ability to delete in batch. |
| This is still in draft as a new feature. | Though the Jira is new, the ability to delete has been discussed for some time. We can already delete items and holdings one by one but not by batch. | we are paying to do our imports another way because of a lack of functionality. | yes. | ||||||||||||||||||||||||||
| 2023-05-12 | I was under the impression that Data Import job profiles could handle incorporated a list of actions to do on the record. In this way you could have a list of common actions for action profiles and then create jobs by reusing those action profiles. It is not possible to reuse more than 2 action profiles in a job. This is extremely limiting. It means that we have to create other job profiles linked to more action and field mapping profiles that increase the number of profiles everyone. |
| P2 | The Jira dates from 4/24/2023. However, we often find functionality that we think works in DI and it doesn't. | It forces us to build more custom job profiles. In a consortium this leads to an excess of profiles when a mix and match approach would be preferred. | yes | ||||||||||||||||||||||||||
| 2023-05-12 | We aren't able to search or create reports for data across apps. | There is in app reporting. This is cross app reporting and searching. | It forces to rely on an external tool that isn't supported. | yes | Wellesley College Middle TN State University | |||||||||||||||||||||||||||
| 2023-05-17 | Inability to customize displays (at the tenant level), e.g., to hide fields we choose not to use, and/or to create record templates for Holdings and Items in Inventory (Note: this is not about creating custom fields) |
| 2019 | Because we cannot use templates and cannot hide fields we don't use, staff are more likely to make errors. In particular, data is often entered in a "wrong" field because it's there and looks logical but it's not the field we have chosen to use. This causes materials to bounce back from physical processing, so creates additional work for multiple units. | it hasn't killed us yet, but it impacts efficiency, morale, and trust in the system | Middle TN State University | ||||||||||||||||||||||||||
| 2023-05-17 | Inventory search on title retrieves far too many results, and the display is difficult to navigate. |
and others | 2022 for titles, search improvements go back to 2019 or earlier | Unreliable and difficult to navigate search results lead to staff not finding records that already exist. Duplicate records are created, and materials that have already been cataloged as serials get cataloged as monographs. | yes | |||||||||||||||||||||||||||
| 2023-05-18 | Amanda Scott | The inability to easily bulk edit instances/MARC, holdings (all data points), and items (all data points) severely impacts our ability to do large clean-up and/or reclassification projects. Many of these projects now have to be done manually and slowly (record by record) or via an extract/transform/load process. | https://issues.folio.org/browse/UXPROD-868 and others | 2018 | Projects in cataloging, continuing resources, government documents, special collections | We're living with it, but it's frustrating and making this many changes manually introduces more opportunities for errors. |