Group

Name	Organization	Function/Title/Notes
Stephanie Buck	EBSCO	Product Owner (Dev team - Firebird) ssbuck@ebsco.com
Patrick Roth	GVSU
Katie Motush	GVSU
Brian Merry	GVSU
Jeff Daniels	GVSU

Goals

What is the problem?
- We are currently unable to remove items from the remote storage database without manually going into the database and removing the barcode.
What are we trying to solve?
- The process outlined above is time consuming and must be done one at a time by a system administrator. We’d like a more efficient way to do this that would not require direct access to the remote storage database
What does the user need?
- We need a process within the FOLIO interface for removing items from the remote storage database. Ideally, when the permanent location is changed from a remote storage location to a non-remote storage location the item barcode would be removed from the remote storage database and if an item is marked as withdrawn, the item barcode would be removed from the remote storage database.
What is the benefit/value to the user?
- A more efficient way of removing items from the remote storage database will allow us to do collection management of the collections held in storage. This is not currently possible to do because of the time it takes to remove items manually. Additionally, having excess barcodes in the system makes remote storage reporting more difficult. We use these reports to give numbers on estimated fullness of the system, percentage of items in the remote storage system that have been called out, etc.
What are the most common use cases?
- Items are permanently being moved from remote storage to open shelving
- Weeding/discarding items from the collection
What are the edge cases to be accounted for?
- When items are accidentally given a remote storage location and saved they are automatically added to the remote storage database. When we change the location to something else we get a message saying the item is being removed, but the barcode is not being removed from the database.
What are the workflows that need to be covered?
- Marking an item as withdrawn (item status) should remove the item barcode from remote storage database
- Changing an item's permanent location to a non-remote location would remove the item barcode from remote storage database
What performance metrics should we use?
- Items can be deaccessioned one at a time
- A collection of items being deaccessioned together - items moving or being permanently removed from the collection
- A few hundred item records to several thousand records - no more than 10,000 at a time
- FOLIO needs to function as expected while deaccessioning occurs

Notes

Locations are set at the holding level, not at the item level
- If a holding has a remote location and is changed to non remote, all of the items associated with the holding will be deaccessioned, since the items inherit the holding location. Minimum items in a holding 1 to 2; maximum 300-400
Item temporary locations used for display or reserve locations
Item records should still exist within FOLIO
Remote storage expects message from FOLIO with syntax for deleting/removing item
- Is there a response to FOLIO?
FOLIO needs to know to not send the same message repeatedly if StagingDirector sends back an error
If StagingDirector can't delete/remove the item barcode, user needs to know

Browser not supported