FOLIO UI: Queue/Task/Request-based Workflows

Hi all,

Originally at Lehigh we really wanted to make OLE really special by integrating in some concepts we learned from our front line practitioners. And building in the functionality piecemeal wasn’t going anywhere so we decided that a more holistic solution was needed. Our understanding of library workflows is that our staff create workflows around “objects” that reflect their daily work. These include:

-Patron requests
-Tasks and Chores
-Projects

And these tasks are often easily divided up into categories/queues so that they are neatly organized.

You may notice that that very short list doesn’t include bib records, invoices, receipts, purchase orders, etc. Those types of docs remain important to the task at hand, but they are merely associated with it rather than being the central focus. And tracking each step of the process (and identifying the beginning and ending points) are what keep people on task and help give a strategic overview of what is being done.

Our proposal was to make OLE revolutionary by including a task/request-based workflow management system that was directly integrated with the ILS itself, rather than a standalone system. We wanted it to be flexible, extensible, and customizable in a way that reflected the differences between libraries, so each and every library could customize the layout and hierarchies that defined their workflows. There was also a focus on the design so that it kept communication to patrons (or other staff) as an integral part of the process (rather than an afterthought) and that statistics should be built into the process as part of evaluating the workflow setup.

This has several benefits:

-Manager oversight over tasks/projects
-Enhances patron communication and relations
-Intuitively allows users to see the progress and flow of their work
-Prevents losing track of work
-Directly links the tasks with the relevant library docs/data
-Standardizes evaluation of workflow progress

The “core” spec we wrote expresses this overarching idea that a flexible and extensible system is good for library workflows: https://docs.google.com/document/d/1WHuXS38S9QRbawBsc7zMI6ZT47kdwqHYKC-HuIOm0dQ/edit?usp=sharing

And even if we weren’t able to build something more forward thinking, we came up with additional specs that would give us some of that functionality, but focused on several of the more labor/tracking intensive tasks in the library:

Usage Case 1/Additional Spec: https://docs.google.com/document/d/1XFJAzfqMsV1l4vvdNGE-UilQf94zey6DiSfsm3GUGoU/edit

Usage Case 2/Additional Spec: https://docs.google.com/document/d/19dqOuKV-Dv-JYRuxB0-DYOl0uEgDReqVvtBCG0hIOvo/edit?usp=sharing

A lot of this thinking was greatly influenced by our implementation of the GIST addon (created by a dev team at SUNY Geneseo) into our ILLiad self-hosted installation. In a sense this was a “proof of concept” that a queue/task/request based workflow management system could be extensible enough to greatly enhance a workflow for which it had not been designed (details in the first Google Doc).

This is hard, but I also think this is very important.

It’s also important that workflows can trigger other workflows.

Example:
Patron submits a request to page an item from branch1 to branch2 triggering the workflow for paging items between branches.
Library staff fail to find the item on shelf, raising an event. This event triggers two new workflows: a workflow for lost items, and a workflow for interlibrary loans. The original workflow for paging items completes.

Of course, some libraries may not want this kind of hook up between workflows. Some libraries may want this only for some patrons, some branches, etc.

I think workflow instances and the events of workflows are valuable sources of statistics.

Workflows instances can also be a great place to store the “working state” of the LMS. A circulation workflow can store the paton, the item, the due date, where it was loaned from, and so instead of storing this in an item record. This makes semantic sense to me, because a circulation of an item doesn’t change the item itself and so the item record shouldn’t change.