2022-12-12 Item State Working Group

Settling in - updates from Erin

(reminder to Erin, turn on subtitles and recording

Begin with discussion about scenarios and pulling back up from user interface / deeper discussions. Does this make sense?

JS: Agreed that you don't want to make people to have to use a process artificially.

AL: What would actually automatically change a Needed for and Process value? A check-in? A check-out? EG, if we are pulling an item because it has a Needed for of original cataloging, when would the automation of saying "this thing is in a process now?" happen?

EN: If you're pulling something from the shelf, once you have it you want to stop requesting. So that means changing the item status at that point. But you don't want to require a non-circulation person to use the Check in or Check out app....

AL: Worried about a Needed for and Process not clearing out and something getting stuck in a loop.

BV: Thinking about the opposite question - preventing a process from inappropriately clearing out.

General question - how do we build this without knowing that we have a workflow engine in place?

AL: You'd want a transaction log to happen, and you'd want the transaction dates to appear in the UI.

EN: If you take a sample Needed for value like "X", do you want to be able to say "this thing can only be removed in Inventory", or do you want to be able to say "This thing can be removed in inventory and in Check in but you have to confirm in Check in?" Like, how would you want that to behave?

EN: I think I should take time to write some specific use cases around how we would use specific processes and needed fors, to see if we can uncover some patterns that would suggest how to think about this with and without a workflow engine.

JS: We need to be able to manage these in bulk

EN: Yes - you can expect that there would be requirements for that.

Search and filtering

Discussion focused on the fact that we have an existing solution. Does adding custom item statuses, needed fors, and processes change the problem we're solving with that existing solution? 

Group seemed to be on same page that the work was to extend the existing solution because the problem was still the same, so you could 

• search using CQL queries for custom statuses, Needed for values, and Process values
• Have custom item statuses show up as values in the existing item status filter if they were assigned to an item record;
• Added filters for "Needed for" and "Process" to the item search & filter pane.

Want to make sure that searching obeyed staff suppress (not yet implemented), but everything else should just be an extension of existing functionality.

Orders, Receiving and Serials

Serials is included here but is a big TBD - BV: We should involve folks in functionality discussion who would use that app more than the people currently on the call.

JS: Clarification - the part about closing an order changing the item status to Order closed only happens if the closure happens before the item is received.

JS: Also important to remember that not every school will create an item record when a serial is received.

Discussion of use cases:

JS: We had a problem after go-live that had to do with workflows for patron holds on on-order items. No indication given to staff during receiving that the item had a hold. Could item status help?

AL: Could Needed for be a trigger for a rush request in the receiving app?

BV: Not for Duke since we only do rush on order placement by staff - getting notices about patron holds after order creation would be very high volume. But still an idea some libraries could use.

TT: We have a manual rush process - LD would know more about how it works. What about reserves?

BV: At Duke, Reserves are separate use case. We know when the order is submitted that it needs to be rushed.

JS demoed a receiving example at UChicago after we could not get an example working on Snapshot.

Question: what kind of use cases do we have here? Discussion will need to resume in January.