2018-07-02 Resource Access Meeting Notes
Date
Jul 2, 2018
Attendees
Andrea Loigman
Jana Freytag
William Weare
Emma Boettcher
David Bottorff
Deb Lamb
Joanne Leary
Anya
Darcy Branchini
Tania Hewes
Discussion items
Time | Item | Who | Notes |
|---|---|---|---|
5min | Housekeeping | Andrea Loigman |
|
55min | Item Statuses con't. | Emma Boettcher |
Notes
Emma on Item Statuses
Emmas question for the group: What does it need for a status to automatically go through to "need for" and/or "process"? (I might got this one wrong please feel free to edit this, thanks)
Summary: We went through the Item statuses again and several new questions came up
Questions/notes:
Which statuses are workflow relevant?
Which statuses are relevant for the workflow engine?
If the workflow engine exists some Process statuses are perfect for it
Needed for statuses are step 0 statuses
David: What is reasonable for V1? Should it be more intelligent & automated, what is needed for presentation e.g. a patron request is only automated
Main Questions, that statuses need to answer to:
Where is the item?
Where does it need to go?
What to do with it?
For that do we need to look at only the availability statuses or also at process?
Requests:
Are we in need for a 4th status for requests?
David reports from the request sub group:
on loan screens you need to know a few things about request statuses:
next due date or item status
what state is a request in
what type is it
only existence
there will be request types which can be put in to loan engine
Andrea: What would make it easiest for the staff to react to a patron asking for an item?
no pop up for every processing status but the availability status will do
more info will be available in different places
Search:
Are we in need for an invisible availability status (unavailable) rather than a concrete status?
David suggests that more Info in e.g. preservation or in house is good for the search so that you know where to look for it
1-2 more statuses are needed to reflect that
Custom statuses:
David stresses that custom statuses are needed not only to create them but also to connect them to each other
Other concerns:
Most important info is where does the item go next
Tania states that the questions are: Which of these things FOLIO does and what a human need to do or have (automated vs. manual process?)
request group will be back soon to present progress
process statuses may need be better structured
Task for next meeting: Think about other things in categories or other examples.
Hi RA-SIG, our colleague Jarmo Schrader (SUB SIG Reserves) asked to comment on the item statuses.
It may be helpful for our next meeting?
Greetings
Jana
Comment:
Concerning the discussion about item status and how it relates to processes I have the following comments and suggestions:
The availability-status is pretty straightforward: the statuses are mutually exclusive, an item always has exactly one of those statuses. And we can probably agree on a common list of statusess that all libraries can live with.
With processes and "needed for" things are different. Basically, we want to know whether an item is currently part of some process and what will happen to it next (what it is "needed for") so we can hand it over to the appropriate person / department / FOLIO workflow. But an item might actually be needed for several things at the same time and be part of multiple processes. And there is a huge variety of processes, that an item can be associated with, so it will be impossible to come up with a useful list up front.
I think a better way to model the association of an item with processes would be to use a queue, similar to that for requests: Each item has a "needed for" queue and whenever a process needs an item, it will add its Name to that list. And whenever an item becomes available, the workflow engine (or a human) would then look at the queue and hand the item over to whichever process is at the top of the list. High priority processes might be able to skip to the top of the list.
- "Process" in this context could be an automatic workflow or something triggered by a human.
- Each process would add its ID and a human readable Name (e.g. "Reserves", "Preservation", "Digitization" etc.) to the queue
- Libraries would be able to define their own processes which could either be actual FOLIO workflows or just placeholders for some process that happens outside of FOLIO (e.g. Digitization)
- Probably this "needed for" queue would have to be integrated with or be part of the requests mechanism.