Skip to end of metadata
Go to start of metadata

October 2021 - a Bulk Edit working group has been formed, and the use cases that used to be on this page are now in their wiki space here: Bulk Edit Use Cases

Please make future updates on the new page.

15 Comments

  1. I added my name to the issues that I edited and/or added to.

  2. I added clarification that Batch delete cases are also in scope of the Batch edit Jira (and thus in scope for the use cases in this list)

  3. I wonder if we do need to see if there is any overlap between use cases. For myself, I need to bulk edit in terms of adding/remove/changing information in MARC SRS, instance, holdings, and item records. This could be related to updating location information to removing or adding statistical codes or notes, fixing urls for eresources. This work is not just for quality assurance but also reporting and collection management (moving collections, items for events, etc.). The work of batch edits relies on being able to effectively find and identify the records you need to edit. Having a strong, effective, and accurate search is a must. Also, the ability to work on sets not just in terms of doing bulk edits on records in those sets but also working with sets from saved searches to filter down to records you need to work with. In Aleph, you can save search results and then manipulate those further with boolean commands like and, or, first set but not second, second set but not first. In Alma, there was the possibility of having dynamic sets where if any new records or update records in Alma fit the search parameters then that record was added to your set. This was fantastic.

  4. Hi Jennifer EustisI agree with everything you say above. It would be good to add that info as a comment in the Jira epic. As for checking for duplication/overlap between use cases, I would expect that to be done as part of the planning/requirements writing for the Epic and its features. For now, on this list, I'm mainly thinking we gather use cases and not worry too much about overlaps. But if you want to "me too" any of the existing ones or add notes to them, absolutely do that. Thank you!

  5. Nice list! I would say that $4 (Have the ability to identify all holdings with location A and change them to location B.) is of high priority for us at Chalmers. Could you explain what  the workaround "ETL" means, Ann-Marie Breaux ?

  6. Hi Marie Widigson ETL means: Extract, Transform, and Load 

  7. Thanks, Charlotte Whitt So ETL is to take the data out of FOLIO, edit in with another tool and then upload to FOLIO using Data import? Sorry about the lack of knowledge in this area.

  8. Hi Marie WidigsonYes, exactly. Export from FOLIO, update the records in some non-FOLIO editing tool, and then re-import them.

  9. Ann-Marie Breaux Should I have access to edit this page? I don't seem to.  I have several use cases to add including fund changes and vendor changes on pos.

    1. Hi Scott - you need to be logged in, and then you should be able to edit it. Check the top right of your browser screen - is there a login button? 

      1. Once logged in, you'll see an Edit button: 

  10. Replacing Voyager's pick and scan would be helpful for us and we could demo that but it would need to be before we go live on folio. Let me know if interested! Also, I think permissions would need to be an early part of the design here but that doesn't really seem like a use case.

  11. Also just wanted to raise the issue of how to handle data elements that need to be protected from batch updating. For example, if items are Checked Out, the item status should presumably not be batch updated to a different status, since there's far more than just the status itself that needs to be resolved (loan records, fees/fines, etc.).

  12. That's a good point, David Bottorffand should be included in the requirements. Data Import has a setting that allows for protecting specific MARC fields, as well as overriding those protections. Seems like bulk edit needs to be able to honor and/or override those protections, plus something that may be considered for other record types.