Page Comparison

Data collision happens when a record is acted on simultaneously by two agents (batch load and/or human for example) causing the record to not include both sets of updated data. These issues can also happen when the changes are unknowingly sequential instead of simultaneous.

This can happen when 2 batch updates are in conflict, when a batch update happens while a staff member edits a record, or when 2 staff members attempt to edit the same record at the same time.

The user should be notified when the a record they are about to save has been updated since the time that they opened the record.

--capacity limit, productivity loss, data Integrity/loss

01 – Extreme

all staff

patrons

UXPROD-3058

UXPROD-2796 

UXPROD-2797 

UXPROD-2798

Much of our current efficiencies are hinged on the ability to change many records at one, to bulk edit or make global changes.  Processes like these have meant that the reduction on staffing levels has been possible without too much negative consequences to our services to patrons. 

Lack of bulk edits impacts DUL heavily partly due to staffing decisions and levels. Impact is cross-function and cross-app.

In-depth analyses for the use-cases of bulk edits, as well as potential work-a-rounds are listed on this MMSIG page.

--productivity loss, data integrity/loss, capacity limit, functionality

02 – Extreme

all staff

patrons

Data import hinges on the ability to extend metadata from one data source into another, and on the ability to troubleshoot loads that cause errors in real time.  Additionally, the ability to roll-back a record load if errors are discovered during data import is not possible.

The ability to have "MARC to MARC" match routines which allows imported records to overlay based on locally set criteria is imperative for our data-flows.  We rely on vendor record numbers which may not be held in the MARC 035, for example.

--data integrity/loss, productivity loss

03 – Extreme

technical services

LSIS

patrons

UXPROD-1383
UXPROD-2200
UXPROD-2741
UXPROD-2742
MODSOURCE-446

We cannot delete bibliographic or holdings records from FOLIO either in batch or individually.  Having extraneous data can adversely impact the performance of the system and cause confusion to staff.  Record deletion from Inventory and the SRS is a necessary part of maintaining efficient workflows and data integrity.

--productivity loss, data integrity/loss, reporting

04 – Extreme

technical services

LSIS

Staying in compliance with the ANSI/NISO standards for holdings data is crucial to the stability of data management.  In order to avoid deprecation of rich holdings data in FOLIO and future systems, maintaining use of this industry standard is needed.  Data loss and deprecated services to patrons is the danger in implemented the FOLIO holdings format.

Ability to import, store, edit, view, create MARC holdings records, and link those underlying SRS records to Inventory holdings records so that the source of truth is the MARC record in SRS. 

--productivity loss, data integrity/loss

05 – Extreme

all staff

patrons

UXPROD-2957  

UXPROD-1575  

UXPROD-1575  

UXPROD-2958  

UXPROD-2959  

UXPROD-1448

Staff need to be able to trust that the working profiles are correct.  Out-of-date job profiles could result in sending inaccurate data to vendors (i.e.: authority control vendor systems), work-a-rounds that include export, edit in a 3rd-party system, and re-import could cause data loss, and loss of data integrity, exporting data for Books & Media, Summon discovery, WorldCat and RapidILL could be compromised. IPEDS, ARL, and local statistics in use for planning and trend analysis are also fragile based on this gap.

Based on some criteria (order info, invoice data, bib data, etc.) export a set of MARC records (BiB, HOL, AUTH) as a .mrc file.

--data integrity/loss, productivity loss, budget implications

06 – Extreme

all staff

patrons

Staff regularly export data in delimited files (i.e.: csv=excel) for reporting purposes, or as the base for running other batch processes, or for manual clean up projects.

Requires ability to export certain elements from across the various functional areas, not entire MARC records, Order records, etc., but elements of those records.

--productivity loss, reporting

07 – Extreme

technical services

assessment & user experience

collection strategy & development

UXPROD-977

UXPROD-2679

Staff routinely move holdings records and their associated items from one bib record to another in batch as well as manually, especially for serials maintenance, but also for error clean-up.

Items are moved between holdings records on an almost daily basis as materials are moved (i.e.: to the LSC). Being able to update these relationships in bulk is a key piece of functionality.  If there is a delay in knowing where materials are, then our service to patrons will be limited.

Lack of bulk moving records impacts DUL heavily partly due to staffing decisions and levels. Impact is cross-function and cross-app.

--productivity loss, data integrity/loss, reporting

08 – Extreme

patrons

UXPROD-2628  

UXPROD-2960

Currently, we have hundreds of thousands of materials that are bound together with other titles, creating a "bound-with" item record.  These are difficult to manage in our system, but are much less so in FOLIO.  Some bound-with features have been developed by the only way to create or maintain bound-with item data in FOLIO is through API.  This means that creating, editing, or deleting bound-with data is not possible in FOLIO.  Even viewing bound-with relationships is not possible until the UI is developed.

--productivity loss, data integrity/loss

09 – Extreme

all staff

patrons

UXPROD-2855  

UXPROD-3080  

UXPROD-1241

Mark for deletion is the method in use to prevent some staff from accidentally deleting needed instance records. Marking for deletion would allow for assessment of marked records' associated data prior to batch deletion.  There is no reliable, sustainable work-around in FOLIO to accomplish this workflow.

--productivity loss, data integrity/loss, reporting

Moderate

technical services

LSIS

UXPROD-1363  

UXPROD-2961  

UXPROD-3092

To be able to keep productivity statistics in place of the CID field in Aleph which allows us to track production statistics, evaluate processing queues, and is used in troubleshooting.

--reporting, productivity loss

Moderate

technical services

Any FOLIO property (title, author, subject, etc.) can be represented in more than one script. All scripts are graphical representations of their related language.  The inability to display or search by these elements in the vernacular, original script impairs efficient processes.

--functionality, productivity loss

Significant

technical services

access and delivery services

The ability to maintain relationships between data among apps when holdings/items are moved from one instance to another, or when data is updated, is paramount to efficient workflows and data integrity.  Dynamic links between apps are present, but break when data is updated (i.e.: titles are changed through record overlay).

Staff should only be able to intentionally break relationships between record types.

--data integrity/loss

technical services

access and delivery services

patrons

Numerous enhancements to searching and filtering are needed in Inventory. Elastic Search, if implemented, may solve many of those problems. Many search-related JIRAs are paused while we await the development of Elastic Search. 

For example, search results show an estimated number of results, not an exact count.  This makes processing batch changes more fragile.

--productivity loss

access and delivery services

There is an overall lack of keyboard commands in FOLIO, meaning everything has to be done with mouse clicks for menu and record navigation.  Additionally, the lack of these  prevent sophisticated macro development in third party systems such as MacroExpress.  Additionally, built-macros to create new fields or records (i.e.: the F-keys) do not exist in FOLIO.

--ergonomic injury, productivity loss, data integrity/loss

Significant

This includes numerous improvements to the navigation experience in FOLIO which right now is very confusing because it is not very intuitive. For example, currently, you cannot search by item data (like barcode) and be taken directly to the correct item, which is something of an industry standard. Likewise, you cannot search for holdings data and be taken directly to the specific holdings record.

--productivity loss

technical services

access and delivery services

Freezing a Patron Record

Impact Analysis - Freezing a Patron Record

Faculty

Staff

Students

Notices come from single address

Impact Analysis - Notices come from single address

Library staff

Faculty

Staff

Students

Recommended workaround: _______

Cost to implement workaround (e.g., "3 weeks of developer time") _______

Impact of implementation (service reduction, slowdown?): ______

Optimistic Locking is FOLIO's first pass at providing record integrity support for multiple users accessing a single record and preventing data being written over / corrupted.

Optimistic Locking is scheduled for basic implementation in Kiwi for the Inventory app, but is not yet scheduled for Users.

Impact: It is a not-infrequent occurrence for two resource access staff to open the same user record at the same time. Aleph prevents the second user from opening the record - FOLIO will not. No workaround is available

Library staff

Data

We have thousands of records that have spaces at the end of the barcode. 

With our Juniper upgrade, our barcodes were loaded with no space at the end.

This means that a checkout succeeds, but an inventory search with the barcode scan fails, until you take the space off the end of the barcode. 

More to come on determining path/impact.

CIRC-1293

UXPROD-3473

No ability to identify items/group combos that are eligible for Scan and Deliver service

/wiki/spaces/LIB/pages/34912849

Currently, we implement Scan and Deliver (basically a version of document delivery) in the CRS. Eligibility for scan and deliver depends on patron group and item information and is generated as part of the circ rules using Aleph's photocopy settings.

FOLIO does not have a similar area of settings that we could easily identify to enable this as part of circulation rules. If we need to continue Scan and Deliver, it will need to be built as part of the requirements for the new catalog request system, and we will need to decide how those items will be identified. 

Faculty

Students

Inability to restrict pickup locations or delivery options by material type, loan type, patron type or item location

Inability to override requests blocked by request policy

Impact Analysis - Inability to restrict pickup locations or delivery options by material type, loan type, patron type or item location

When a patron places a successful request for an item, they will be able to ask to have it delivered to any pickup location in FOLIO. E.g., we will not be able to say that grad students can page items from Music but only for delivery to non-Music locations. Or, we won't be able to allow delivery of items from the LSC to campus but only to the library that sent it to the LSC in the first place. 

Impact: Significant - this is one of the biggest RA gaps. We would have difficulty coordinating access to certain LSC materials, and expect that some libraries would choose to not allow some patron types to request delivery of their materials at all. We would likely need to end service to some unstaffed pickup locations, including ones where faculty and grad students are heavy customers. There would also be issues in the requesting system, especially for DKU patrons who would see Durham pickup locations regardless of choosing a DKU item to request.

Related to this is https://issues.folio.org/browse/UXPROD-2649 - overriding requests that were blocked by policy. That one is an R1 and is also not scheduled. If that doesn't make it, there will be no way in FOLIO for staff to be able to request an item that the patron was prohibited from requesting. 

One approach to the inability to override requests could be creating users that staff use to request these items on behalf of, and then using a special patron group to ensure that those match. 

Library staff

Faculty

Staff

Students

UXPROD-1561

UXPROD-2689

UXPROD-2649

Library staff

Faculty

Staff

Students

RA

jiras remain open; comments and convo with cornell suggest work has happened, but unclear as to how that is being documented or contributed back to community

chicago's performance so far seems promising (they went live MLK weekend).

Supporting DKU (multiple tenant level locales)

Impact Analysis - Supporting DKU

Right now, FOLIO has one tenant-level locale which means that everything runs in one time zone. For DKU, that means that notices, UI display, and other timezone features will not reflect their time in China.

Impact: There would be significant confusion in the UI for DKU library staff that would likely impact their ability to deliver good service.  

Library staff

Faculty

Staff

Students

Inability to control requesting behavior for various item states

Impact Analysis - Inability to control requesting behavior for various item states

To get the first round of requesting live for Chalmers, the RA SIG agreed to hard code behavior for requesting around specific item states. (That is documented in the FOLIO community wiki here - https://wiki.folio.org/display/FOLIOtips/Request+Type+Whitelist+Matrix - see "Whitelist.")

There is a feature to add the ability to configure these settings independently but it has not been developed.

Impact: The agreed-upon whitelist allows patrons to place requests on missing items. This would be a significant departure from our general approach to customer service and we'd need to invest development time in figuring out how to work around it / redirect eligible patrons to interlibrary request.

Faculty

Staff

Students

Lack of item status history in the UI

/wiki/spaces/LIB/pages/34912560

Resource Access staff frequently need to track down items that are not where they are expected to be. A key tool is being able to view an item's history - to see when it was last "touched", when it last circulated, where it may have been requested.

FOLIO's circulation log app has some features that support this, but a major missing feature is the ability to track transitions in an item state - for example, to see that an item was requested, but then declared missing a week later.

Impact: There are no workarounds for the lack of this feature. We will likely see a slowdown in staff productivity, and loss of some library materials because they cannot be found when they go missing.

This item status does not exist in FOLIO, so Items that are returned will go immediately to 'available'. Not all libraries use this status, but DUL does.

Patrons who frequently use the onsite collections at Perkins learn where "reshelving" items are and go to the area on the second floor. 

Impact: Without this feature, patrons will go to the shelf expecting an "available" item that may have just been returned an hour before. Patrons will experience confusion and frustration not finding an item on the shelf that they expected to be there.  There is no workaround. 

Library staff

Faculty

Staff

Students

UXPROD-527

When an item is received in FOLIO, it gets a status of "In Process." If other workflows also use that status, it will be difficult for staff to know if an item has arrived / is possibly at Tech Services.

Impact: Staff frequently use the Arrived status in FOLIO to troubleshoot item delivery and provide information to patrons about the status of ordered items. There is a workaround for this, but it will be time consuming for staff.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

There is no ability to delete or cancel a loan through the FOLIO UI. If a loan is generated unintentionally, either by a staff member or an automated process, the loan will have to be discharged to get it to clear.

This may lead to data integrity and reporting issues. May also be an issue with LSC and returning items that have been hanging around "In transit."

Impact: Deletion via the API is a workaround, but could also lead to data integrity issues. Loans can also just be returned to close them.

Library staff

Data

FOLIO anonymizing features are incompletely implemented. Custom fields (where we are keeping demographic information) are not retained on anonymization, nor is the user department field. If we choose to do across the board anonymization, we would lose important reporting data.

Impact: We have decided not to anonymize until our needed features are built. Anonymization on demand for a single user will be available, but decisions will need to be made about how to advertise that service and how to assess potential impact on reporting data.

Faculty

Staff

Students

Data

UXPROD-2217

UXPROD-3037

UXPROD-2062

We will have no automatic renewal functionality. 

We'd like to end automatic faculty renewals for DUL as a whole, but there will still be needed use cases for smaller groups and/or for COVID response.

Theodore Tolstoy from EBSCO has a python script that can be used to edit due dates for open loans - https://github.com/FOLIO-FSE/FOLIO-backup-and-restore/blob/master/service_requests_tools/extend_open_loans.py - cludgy but possible to leverage for this. Chicago also has tools they are using for this. 

Batch renewal is also listed as use case 38 for the bulk edit app - https://wiki.folio.org/display/BULKEDIT/Bulk+Edit+Use+Cases

Faculty

UXPROD-2375

UXPROD-3651

UXPROD-2479

UXPROD-2648

This is something staff have relied on to protect patron information. It will be a training issue that we will have with staff.

There is a timeout option for check-out (Settings > Circulation) and we can investigate having it timeout.

Backdating returns has traditionally been something we have kept tight control over because it has the potential to result in mischief (or have friends pressure their friends who work at the library to help them avoid a fine.)

This is very unlikely to be developed anytime soon and backdating is also not in the circulation log.

UXPROD-3157

UXPROD-3579

FOLIO has no defined support for offline transactions. 

Aleph does have support for offline transactions, though it is very tricky and easy to mess up, so not all libraries use it consistently.

We will want to define a CAST-wide workflow and policies for how we do checkouts if FOLIO is offline.

FOLIO does not handle "print screen" well at all and there are no built-in features to support printing ad-hoc check-in receipts. 

Aleph doesn't handle this very well either; this will be a training issue. The best option will be to screenshot the check-in screen and print the screenshot.

Library staff

Faculty

Staff

Students

Faculty

Staff

Students

IPS: AP

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

IPS - CD

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

IPS - CD

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

IPS: RO

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

IPS: 

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

IPS: XB 

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

IPS: "CB - Commercial Bindery, OB - Out to Bindery, PB - Bindery-Boxing, RB - Ready to Bind, IB - In Process-Binding, BD - Sent to Binding"

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

IPS: TS

Resource Access staff make heavy use of a variety of item process status values to enable tracking of items as they move through the library, and to provide correct information on an item to the catalog request system (e.g., to disable requesting if an item is not on the shelf.)

FOLIO's original design assumed a three-part item state field that was meant to provide extensive flexibility for supporting item tracking workflows. Only one of the three pieces has been developed - availability - and the current list of item statuses for availability does not adequately match our use cases. 

Impact: There are workarounds that can be defined in these cases but they are time-intensive, will impact staff productivity in all departments (not just Resource Access,) and will increase the amount of time that materials are not available for patrons.

There are a number of open jiras that touch on item state. A few select ones:

UXPROD-1590

UXPROD-1530

UXPROD-1927

UXPROD-2606

Data import for MARC Invoice and MARC Order data

Lehigh developed a temporary solution that UChicago has expanded. 

• Wiki page with more information about Lehigh solution:  https://wiki.folio.org/x/j4DhAw
• UChicago branch in GitHub 
• Per Kristin Martin "Chicago intends to use the Lehigh orders app to build the orders. Then we would need to load the full catalog records through data import, which would overlay the brief inventory records. We are going to use a Google sheet script to build the invoice lines and then load those."
• Per Christie Thomas on 2/6/23, the google app times out at 30 min, so they can't process invoices with more than 200 lines.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  Current acquisitions staffing levels rely on automated processes to load invoices and order data so that they do not have to be manually keyed. If we are unable to automate the import of MARC invoice and order data, Monograph Acquisitions staff will not be able to handle the current volume of ordering and invoicing that DUL does. If these functions are not automated, and we want to get all of our orders placed and invoices for them paid in the appropriate fiscal year, then we need to add more staff time. Alternatively, we could reduce the amount of ordering we do. Not paying invoices in a timely manner isn't an acceptable alternative.

Extreme

Capability

Library staff and patrons

UXPROD-663

UXPROD-185

UXPROD-191

RM

Expected in Nolana (R3 2022)

UXPROD-663 has been dropped from Orchid

Aleph automatically handles arriving materials as part of the MARC invoice loading.  There isn't a distinct JIRA to describe this feature, so we need to make sure it's included in the development of MARC invoice import UXPROD-663. Dennis Bridges created a wiki page to describe requirements.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  Current acquisitions staffing levels rely on automated processes to automatically arrive materials as part of the MARC invoice loading process. If this has to be done manually, and staffing levels and ordering volume stays the same, then we will develop backlogs of material waiting to be arrived. This means that it will take significantly longer for newly acquired materials to become available to patrons.

Library staff and patrons

UXPROD 3227 was created on 8/24/21.

RM

Not scheduled.

Serials check-in

See Impact Analysis: Receiving

Lack of prediction patterns in FOLIO will require staff to enter information about each piece as they arrive rather than checking off arrivals from a system-generated list of expected pieces. 

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  Current acquisitions staffing levels rely on automated processes to generate items for each issue of a periodical that arrives. If the current volume of periodical orders stays the same and staffing does not increase, then we will develop a backlog of periodicals issues waiting to be manually added to FOLIO. This means that it will take significantly longer for newly arrived materials to become available to patrons. Furthermore, the manual creation of all data for every single new issue greatly increases the risk of inaccurate data being introduced into the system, thus reducing the discoverability and accessibility of these materials to patrons.

Cost and Quality

Library staff and patrons

UXPROD-194

See Impact Analysis: Receiving for more info about managing this gap.

Not scheduled

Claiming ordered materials that are missing

See Impact Analysis: Receiving

FOLIO currently doesn't offer any reports to identify which expected pieces are missing.

Impact

Missing materials won't be claimed promptly from vendors which means we've paid for materials we haven't received.

Patrons looking for ongoing print materials may not find what they need. As our print serial collections become more and more focused on areas of special focus, the ability to identify and claim materials that may not have arrived is even more essential, not only to make sure we are getting what we paid for, but to ensure that these serials are preserved for posterity.

Cost and Quality

Library staff and patrons

UXPROD-1845

Not scheduled

Not Scheduled

Will FOLIO be capable of storing all historical order data from Aleph?

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  For e-resources especially, access to historical order information is critical when researching disputes with vendors about access - often the order is needed to prove to a vendor that we should have access to something we ordered many years ago. Staff can currently search all orders from within one system.  If they have to search in two places (for example, the LDP for older closed orders and FOLIO for newer orders) it will take longer to resolve issues.

Significant for e-resources/special collections;

Moderate for others

Library staff and patrons

FOLIO doesn't currently support SFTP or SCP secure channel file transfer for the export file of vouchers.  Uses just FTP currently from Settings > Invoices > Batch configuration.  Watching UXPROD-2843 to implement SFTP.

FOLIO doesn't offer any "preview" reports (as Aleph does) of which invoices will be included in a batch export.  The process to validate which invoices are going to AP and to balance the amounts against the submitted paper invoices may be more difficult and time-consuming for staff especially if issues need to be tracked down and resolved.

Impact

DUL Business Services staff and staff at each professional school library who manage invoice feed to AP.

We will spend more time in order to deliver the same capability/quality as we currently do.  DUL Business Services verifies that the totals being sent to AP balance with the totals on the paper invoices submitted for the batch being run prior to sending the data to AP.  This ensures that any errors are corrected within the library system prior to sending the payment info to AP.  If the batch is sent without this analysis step, payment errors will occur which would require significant staff time to untangle.

Significant for e-resources since lack of payment can mean loss of access

Moderate for physical collections

Library staff and patrons

FOLIO lacks the ability to save order and item creation defaults at the user level.  Order templates are available in FOLIO but are shared across all users.  

Impact

We will spend more time in order to deliver the same capability/quality as we currently do. When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials.

This lack of functionality alone could result in order records taking 2-3 times longer to create in FOLIO than in Aleph. At scale, this could significantly impact the efficiency with which the current number of staff can do their work, both in terms of placing orders on behalf of subject librarians and receiving incoming material.

Library staff

UXPROD-1398

Lack of record locking in Orders, Invoices, Finance and Receiving.  FOLIO doesn't prevent two users from editing the same record simultaneously.  Aleph prevents the second user from opening the record.

Optimistic Locking would manage multiple users accessing the same record and prevent data from being overwritten or corrupted.  Scheduled for basic implementation in Kiwi for the Inventory app, but is not yet scheduled for other apps yet.  JIRAs only exist for Orders and Organizations as of 6/21/21.  Julie added a request for this topic to be discussed at a future Acquisitions SIG meeting.

Impact

Data loss/corruption could occur.  This could impact financial records, orders, invoices.  If errors occur and need to be investigated and fixed that will cost staff time to untangle.

Data

UXPROD-3058 

(umbrella across all apps)

• Requires cross-department training on the appropriate material type to apply on an order and to then open Inventory to change the item material type on any items created from an order.
• Requires more FOLIO team time to create circulation rules for order material types (confirm with configuration working group).
• Risk that future cross-app enhancements will send updates from Inventory back to the order and overlay the original material type assigned to the order.  This data loss would impede acquisitions staff's ability to produce necessary reporting on orders by material type.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials. 

Cost

Library staff

UXPROD-2455

Candidate for local development or with GBV/HBZ

not scheduled

FOLIO doesn't support automated requesting from the purchase order, so until UXPROD-2565 is implemented, acquisitions staff will need to do several more steps:

• open Inventory for the ordered title
• change the material type from one of the order material types ("z") to an item material type 
• go the Action Menu - "New request"
• build a request in the Request app

Impact

We will spend more time in order to deliver the same capability/quality as we currently do. When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials.

Library staff

UXPROD-2565

RM

not scheduled

(tagged as "morning glory candidate")

• Workflow change
• Train staff on new workflow

Instance connection of the POL on Open or Closed PO. Discussions at Acq SIG have raised concerns about the use of GOBI API as it's currently designed. 

From UChicago: If we end up with an order attached to the wrong record, we close the order, delete it, go to inventory, and delete the undesired holdings and items. Then we either adjust the import process to make sure it doesn't find an improper match (basically by taking out the ISBNs in the Inventory record, importing the data, then correcting the data in Inventory), or creating the PO by hand where we connect it to the right Inventory record.

Per Dennis B "You could configure the GOBI integration to create Pending orders. This would mean a user actually needs to open them but you could also make adjustments to the instance connect before opening if needed." Need more analysis to determine the possible impacts of turning off automated matching. Talk to UChicago and Cornell about their experiences.

4/12/22 Acq SIG discussion of this topic. UChicago is loading every batch of the order batch load into a test system first due to these matching issues. 

4/2/22 Acq SIG discussion: Bug with the matching was that the identifier type wasn't being included in the matching logic. That has been fixed and if there are inaccurate matches there will now be a way to manually change the instance connection (and manage holdinsg) to the accurate one (UIOR-594).

Impact

We will spend more time in order to deliver the same capability/quality as we currently do. Untangling mismatched orders/instance/holdings could be time-consuming for acquisitions staff.

UIOR-763

UIOR-594

RM

Lotus includes the ability to disable automated instance matching (a new instance/holding will be created for all),

Morning Glory will include the ability to edit an existing POL Instance connection.

Create report to find duplicate instances. 

Placeholder to discuss the scope of invoices data migration to FOLIO 

Note from Virginia: this has only been important for e-resources in my experience.

n/a

Placeholder to discuss the scope of data migration for information about previously received materials - the data captured in the Aleph arrival form and subscription check-in.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  The Aleph subscription log is used to capture notes used in serials management.  Losing access to this historical information about serials could cause staff to spend more time researching issues.

Library staff

• In FOLIO, there isn't a way to create an order from the Inventory app and the title search from the Orders app "create new order" screen lacks enough info to find the correct title. It is difficult to identify which title to associate with an order due to limited information displayed from the search tool pop-up with the New Order screen.  
• Users can initiate a title search from the Inventory app, but once they locate the correct title there isn't currently a way to start a new order from within Inventory, so they have to copy the title name and then open the Orders app to start the new order.
• Implementation of UXPROD-961, "Allow Inventory Instances to generate purchase order and purchase order lines" might help since search is more robust within the Inventory app.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials.

Library staff

UXPROD-961

RM

not scheduled 

(tagged as "morning glory candidate")

• Workflow change - can't start order from a bib
• Train staff on strategies to find the appropriate title

Aleph consolidates key order info in one place.  FOLIO requires the user to switch between the order header and the POL to review key data.  This will slow staff down as they are looking for information.

Discussions about this in the Acq SIG led to feature to hide fields when using templates for order creation to simplify the UI.  This doesn't address the fact that key fields are split up - some on header and some on PO line.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  When considered with other impacts on this list, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials.

Library staff

MODORDSTOR-265

UXPROD-3221

• Train staff to find key data elements
• Design templates to hide unnecessary fields (Lotus)

• Create method to manage routing lists external to FOLIO

FYRO - Ability to process transactions against a prior year budget

FYRO as implemented in FOLIO's Iris release doesn't support the ability to process payments beyond the FY end date.  Feedback was provided to the RM PO about our need to run FYRO 2-3 weeks after the end of the FY to processes any invoices that arrive up until 6/30 and to run reports to make sure one-time orders are paid/closed etc.

The proposed workaround from Dennis B is to temporarily change the FY end date to extend into July to allow processing those transactions and then change the date back to 6/30 before running the Rollover process once we're ready.  Dennis also said in slack, "Obviously this would be dangerous if there were a number of users in the system, so I don't recommend it."  This is not a vetted process and we would need to test to make sure there wouldn't be unexpected consequences of editing the dates in this way.  

Impact

We will spend more time in order to deliver the same capability/quality as we currently do. It looks like there is a workaround in FOLIO (as described above), but we will need to test this and then it will cost staff time to coordinate changing the FY dates temporarily to ensure that the process is successful.

Library staff

Risk that some payments intended for FY A would be charged against FY B instead due to FOLIO not allowing transactions after FY end date.

UXPROD-2713 

• Create a test plan specifically for FYRO to vet the "change the FY dates" process

• There is nowhere to view or store migrated historical order transaction information in FOLIO.  Determine whether this impact can be mitigated through the creation of LDP reports or by adding some order log notes to the notes section of the order in FOLIO - analysis needed (Duke JIRA FOLIO-464 created)
• FOLIO doesn't display a transactional log of order activity.  Aleph allows the user to see a log of all order-related transactions such as changes to order status, item process status, next claim date.  This information is useful for troubleshooting.
• The FOLIO note helper app does support adding as many notes entries as needed and categories can be created.

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  This will make troubleshooting difficult items (e.g. missing items) much more difficult and means less accountability when it comes to problems with issues.

Library staff

Duke JIRAs FOLIO-464

FOLIO-528

RM

Included in Orders data migration script.

Waiting for a load of Aleph orders to FOLIO to validate that the data looks good in the target notes field.

Is overlaying or adding a single bib record as seamless in FOLIO as it is in Aleph?  If not, we should include that impact here since it would slow the work of acquisitions staff.

Info is available here about single record import in the Iris release.  The wiki includes instructions for pushing a record from Connexion to FOLIO and for importing from FOLIO inventory.  There is enhancement work outlined in UXPROD-2912, but not scheduled yet.

To try this, login to the Lotus Bugfest environment (Login: diku_admin / admin). Open the Inventory app. Click "Action" button at top right. Select "Import."  Choose OCLC World Cat and add the OCLC # of the resource to import. Click import. An instance is created.

TBD - not sure how well the OCLC integration works to evaluate priority

UXPROD-2912

Is this still an issue?  This JIRA was updated on 6/15/21 by D. Bridges: "Opting into the "Load more" function of the search results component has improved performance here substantially. Limiting the number of results that will be displayed for any given search."  Need to verify this after the full order load runs.

Determine whether any next steps are needed to mitigate risk, such as creating a custom table in the LDP to store closed Aleph order data rather than loading it to FOLIO (just in case).

Impact

We will spend more time in order to deliver the same capability/quality as we currently do.  When considered with other impacts, what seem like minor inconveniences in using the system are likely to result in a significant increase in the amount of time it takes acquisitions staff to do their work. Backlogs of orders, invoices, and materials will develop, and patrons will experience delays in having access to newly acquired materials.

Cost

Library staff