Please note: This video presents our optimal vision for this feature in FOLIO; What you see in this prototype is what we are working towards in the long run, and might not all be present in the first, developed version. Please help us improve it — share your questions, constructive feedback and ideas in the comments below.
Note, this is not a call for technical assesment — right now, the focus is figuring out what would be the optimal way to build a Workflows app, UX wise. Technical assesment comes, but it comes later 
!Hi all,
UX questions to consider — feel free to comment on discuss with your ideas, advice, questions
In theory I feel all the features I present are meaningful, but in practice I don’t know — that’s what these questions above are meant to clarify
EDIT, August 21, 2017:
• Name examples of workflows that could be done with this concept in a good way?
• Name examples of functions you would prefer were not tweakable in a concept like Workflows?
I think it would be useful to allow a trigger to be associated with several operators not just me or everyone. An example is a group working on a special project to change a set of bibliographic records. Just those records would be exported to a report when a field is changed.
I’m thinking about the workflows and have some thoughts: there are workflows that happen in the system, and where it really feels like this app will help the flow and automate the process when possible. Then there are workflows that happen outside of the system and maybe are more like checklists of tasks that need to done. E.g., I bought a new e-resource and as part of the set-up, I need to update the config file for EZProxy (maybe someday we’ll have this better integrated with FOLIO, but I don’t see it happening for a little while) and I need to send out some sort of publicity announcement. The “I” could be me or some member of a team. I’m not sure how these tasks fit in, under Create Task? I am liking the idea, but it still feels a bit abstract.
Can triggers also be a workflow step? E.g., a record field is change (item status to “lost”) and then a recall on item is cancelled, since it’s not available.
Question
I like these, and could see the workflow app then also being used for batch updating of records. Like, maybe I need to change the vendor on a bunch of POs, could I feed in the list of POs and loop through them and update the fields? Or maybe I want to do a search for POs from a certain vendor, and update to a new vendor only those that are already open. I think the If/else would help here. (The example I think of is if a library switches subscription agents). Or maybe the loop could be used for the batch update of bib records. I’m not sure how bib records will be accessible to the workflow app, but it seems like there should be a connection.
question
I suspect there a lot of libraries where people would like to be liberated from the systems department and be able to create the workflows directly. That said, I think there is probably a point where the workflow engine should focus on simplifying the most common basic steps and apps, and then leaving scripting for more complicated options. If the complicated options are common, then having an easier way besides scripting would be nice.
question
I can see a lot of value in sharing, but some things are going to be institution-specific. For example, if you made a group to be assigned tasks that doesn’t really exist in another library, then that workflow is going to fail. If workflows are shared, some things will break or need to customized to fit the new institution’s particular environment. Steps that don’t transfer to the new institution need to be identified so that the accepting institution can alter them and make sure they work. I see a lot of value in sharing scripts, especially if someone has more scripting experience compared to someone else, this will be an easy way to share that knowledge. It’s sort of like me Googling on Excel and Visual Basic, since I don’t really know VB well myself, but I am able to adapt code to accomplish things that I couldn’t program from scratch.
Thanks for sharing this Filip. I really like the overall concept. Here are some responses to your questions:
How granular should steps be?
I think the steps should be pretty granular. I could see wanting to be able to do things like create a record, add values to fields on a record, activate content in a knowledge base, etc. Another example of a step I could see would be someone (a selector or patron) filling out a form and having the values from the form populate a record.
I also agree with comments from others that it would be helpful to be able to string together granular steps into a block that could then be reused in various workflows. These steps should be able to span multiple workflows. For example, if a license status is changed to “approved,” then trigger a step for someone to pay for a purchase order.
Some notes on non-linear and variant workflows:
Here’s an example from our current CORAL implementation. Because CORAL really only does routing of high-level tasks, none of this process is automated or particularly granular. But I think it’s a good example of the type of workflow we commonly use.
After order records are created, the workflow breaks into two threads: ordering/access and licensing. These are often done truly concurrently – as in it doesn’t matter which one gets done first. But sometimes, we can’t actually place the order until the license is signed. We might know this ahead of time based on the vendor. But we might not find it out until we start the license process. Other times, we actually have to place the order first, because we’re facing spending deadlines. It can go either way (or no way). So we’ve set up the workflow not to illustrate a dependency. Basically the people performing these tasks have to coordinate with each other and make decisions accordingly. I’m really not sure how to solve this problem.
Another area of variance is whether a license is needed or not. Sometimes we know it’s not needed, so we start the workflow then delete this step immediately. Sometimes we think a license is needed, but later we find out it’s not. Then we delete the step later. We we think a license isn’t needed and we find out it is. So we might add it back in. CORAL allows us to modify the “workflow instance” after it’s been create/workflow started. We find this very helpful.
Tasks are very important b/c many workflow steps are manual. I’m OK with the idea that each step in a workflow is actually a to-do – either to be done by a person or the system. We still need stand alone to-dos.
Other thoughts:
A management view of tasks is also important.
There’s a danger in becoming too granular. The more granular you get, the less chance there is that your workflow will match any iteration of a process exactly. It also makes the workflows confusing to create and maintain.
Workflow steps and tasks should have a due date concept. However, the main purpose is to check in and make sure the step is not just languishing. There are often legitimate reasons that things don’t get done on time, so we’d need to be able to review and extend due dates.
How meaningful is it to have logic related steps like if/else and loop?
I really like these. I think they give non-programmers a chance to use some programmatic concepts in an easy way. I see the if/else being the most useful, since we have lots of exceptions and variations in our work.
Which triggers would be meaningful for your work as an individual and for your particular group at your institution?
From an acquisitions perspective, a few meaningful triggers would be:
A selector submits a request for a purchase or trial
An order gets paid
A license becomes active
A change occurs to one of our resources – e.g., a title is moving from Elsevier to Wiley – this might be info that could be pulled from a knowledge base
A resource subscription will expire in X days
Another user completes a task
An email is received
Which steps would be meaningful for your work as an individual and for your particular group at your institution?
Especially at first, we may have workflows that are predominately made up of assigning and completing tasks, rather than automating system-based activity. That’s most in line with our current conception of workflows.
As we get more comfortable with the tool, we may begin to understand how we can incorporate more automated actions. I also really like the form fill step that you showed. Currently, we have templates and macros for certain kinds of purchase orders – e.g., an order for a Springer title always has these values. It would be awesome to be able to put those directly into FOLIO and apply them with just one or two clicks.
The PO template example could be especially useful for automating work. A use case I shared on our call was the example of acquiring a large number of new titles as part of a journal package. For each title, we want to create a PO that has a fairly standard set of values. These might include:
Each order would also have a few unique values:
In the past, we have created macros to do this. We would search for a title, create a blank PO, then run the macro to fill in the default values and have it pause in the appropriate place for people to fill in unique values. This ensures consistency, but it’s slow. It would be great to automate this process.
How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
This is very meaningful. Currently, we can actually automate processes in our ILS using the API. But only one person at our institution knows how to do this and has permissions to do it. This means that most things doesn’t get automated simply due to lack of resources. Anything that can democratize the ability to automate processes would be great.
How meaningful is the ability to publish workflows for others to download?
How meaningful is the ability to publish scripts you write for others to download?
I think it’s very meaningful. While it’s unlikely that a workflow/script will translate exactly between institutions, it’s often easier to start with something and tweak it, then to build it from scratch each time. The workflow store would provide an opportunity for people to share their solutions or get a leg up in creating their a new solution.
What’s missing from this prototype?
Some repetition, but things I’d like to see include:
What works well in this prototype?
On the whole, I really liked this. I think it’s a very clever way to help people create complex workflows without having to be technical experts. The drag and drop UI is really nice. I would be excited to have a system with these capabilities.
Thank you for creating this. It looks really useful. Would these workflows be for individual items/users/orders/etc., or would we be able to apply the workflows to a large collection of items/users/orders/etc. that may be imported through a batch import, or are being removed/moved/otherwise updated in a global update?
Thanks for your question, Steven @stbr2668
The idea is that users would be able to use it on both individual items or on multiple items at once. One could imagine that the batch import of e.g. items would happen through an automated workflow that pulls in a spreadsheet or a folder of files and turn them into records in FOLIO with the appropriate automated actions, and perhaps even creates tasks for manual review of the records that caused errors.
What do you think would make this concept useful?
Thanks for the clarification, Filip @filipjakobsen
I think this would be very useful for many groups (user management, cataloging, acquisitions, more).
This workflow concept would be very useful for our aged bill cleanup processes. Currently, we use MS Access to run a monthly process to find aged bills that meet date and amount criteria. The bills are further sorted into type (regular overdue fine or lost item charge) and owning library. Owning libraries use the lists to either cancel the charges, to search the stacks for Lost items, or to send reminder letters about payment due. The oldest charges (for which the previous steps have already been done) are sent to a collections agency. All bills are annotated and updated as appropriate. I imagine that in the Workflow app, the steps involved in this process would have to be quite granular. The if/else logic would definitely apply. I’m certain it would be helpful to write scripts that could be customized for each library (or to be used centrally). I’m thinking a technically-minded person would be in charge of this broadly, rather than a person in a unit library who was not adept at scripting.
Another process that would lend itself to Workflow scripting is the process of doing searches for missing books (tracers). After a pre-determined number of searches and amount of time, send the information about the missing item to a selector for a replacement decision. Triggers here would be item status, status date, location. (Notifying the requestor about the outcome of the searches and/or replacement decision would also be part of this sequence, needless to say.)
[feedback out of hbz group meeting] The drag and drop surface looks great and is intuitive to work with. It is desirable to have this in the future LSP.
[anonymized feedback out of the Reporting SIG discussion] Use Case 1: trigger will be the calendar (every three month, every year, …); step can be “give me all e-ressource records which I can use remotely (by license)”
[anonymized feedback out of the Reporting SIG] Use Case 2: trigger will be the calendar (every year); “give me all items that have not been used in the last year within the signature space ‘X’”. Then these items will be removed manually.
[anonymized feedback out of the Reporting SIG] Use Case 3: The DBS (German Library Statistics), which has the same variables / parameters every year. One figure of the DBS is, for example, “for the year 2016, please give me the number of loans there were”. This will be run every year in the same way. It is desirable to have templates for the reports of the DBS which can be used and edited by the libraries.
[anonymized feedback out of the Reporting SIG] Use Case 4: The SCONUL Statistics in the U.K. (see https://www.sconul.ac.uk/), pulled every year from all academic libraries in the U.K. It is also desired to have templates for these statistics. The libraries run the reports, then report the results to SCONUL. The SCONUL statistics will be briefly presented in the Reporting SIG on Sep, 11th, 2017.
[anonymized feedback out of the Reporting SIG] Outputs: Need to create output forms (as steps ? As Options / variables to steps ? Finally as Apps ??) like pie charts or bar charts. Implement different ways to visualize the (reported) data.
[anonymized feedback out of the Reporting SIG] The (Reporting) system should be as accessible as possible. It should be operable by people who are not technical specialists.
[anonymized feedback out of the Reporting SIG] Triggers should have help menus (drop down menus or else) for non experienced users. The parameters to the triggers should have help sections.
[anonymized feedback out of the Reporting SIG] Permissions: It should be kept in mind that people, who are granted edit permissions to the Reporting app, will also be able to change bibliographic data sets (when they built scripts in the Reporting scripting language). Care must be taken during the process of developing, editing and debugging the scripts. It must not be possible to change real data during the development and testing of scripts. It must be possible to run the scripts against test data.
5, 6, 7) go hand in hand. Being able to export / publish a workflow for others to use is beneficial for sharing with other libraries. If you can publish then most libraries would like the ability to modify / change code directly after export or before import.
I would agree with this! Conditional logic is essential.
Which steps would be useful?
In the user management area, I can see that it would be useful to have a trigger when creating a person’s permissions. Create the user permissions and then notify the supervisor and/or the employee when it’s completed.
Examples: Setting up Borrow Direct, reporting scripts, exporting of records,
If triggers would be created/used to alert a circulation/fulfillment supervisor/SME post an on-the-fly user record being entered/created. Some of the triggers have an overlap with reporting, but the ability to customize that for different service desks or libraries would be welcome.
My answers to FIlip’s questions above:
My use case: When a guest patron comes in and gets a library card, we might want to automatically provision a guest ID in our identity management system. So, on user creation, we’d want to make an API call to the identity management system to create the guest ID, and then put that newly created guestID in as the patron’s userid in FOLIO.
This is very much related to the use case I had in mind. Agree with the on-the-fly and/or provisional ID/auth. As a former circulation/access librarian, these cards/requests are often created off hours when full-time staff is less available.
I watched this video with a few other Duke employees, and I compiled our thoughts together:
As stated above, the options of Anyone or Only By Me for Triggered by are too limiting. I think in a lot of institutions, the people creating these workflows will not be the people doing the work with Folio, so we’ll need to be able to have more control.
Both in the Triggered by and Assigned to areas, we need the ability to assign groups of users. I believe in OLE this was the ‘role’ concept, so I’ll use that term. We envision a system that allows a task to be assigned to a role and have it show up for everyone in that role. Maybe with a claiming option? I know some of this falls squarely outside the Workflow app and in the To Do app, but there’s definitely some overlap.
It would be good to be able to apply different combinations of boolean logic to the triggers.
I think there’s some confusion about how large batch jobs are run, and what area that happens in. Some of it seems to happen in this area, but not all. Am I correct in thinking that the jobs themselves would be designed elsewhere, and then be able to be run off of triggers set here?
The drag and drop is good, but there needs to be a fully fleshed out system that avoids use of the mouse, for people with accessibility needs and power users who like to use the hot keys.
It would be good to be able to duplicate existing workflows to use as a starting point for customization.
You showed creating custom steps, does that mean we can also create custom triggers?
@dennis and @cmalmbor I would love it if you would be able to provide me with a handful of examples each of situations where the additional specificity is needed so I can make sure we design it in a more useful way
FOLIO should come with default workflows and scripts out of the box so that an institution can start without fiddling with the workflows if the default fits. (There even might be an option to pick the default for a small or the default for a bigger institution when creating the tenant.)
Changing existing default workflows is more easy than writing them from scratch. Therefore the FOLIO’s default workflows should be encoded using the workflow engine and not hardcoded in Java/Stripes.
Independent steps can be done in parallel by different people. They can execute these steps in any order if the workflow engine supports parallel steps.
I like the description field of a workflow. Any user that is involved in some workflow should have access to this description and the rules the workflow is based on. Example: When suddenly buying a book needs approval the user can see the reason why.
@filipjakobsen An example of how we would like this to ideally work would be something like this:
this is probably where the workflow functionality ends, but the rest would look something like this
The key piece of functionality here is the ability to assign things to multiple users instead of just one. Ideally this is done via groups, or ‘roles’, that are defined elsewhere, as this helps reduce the amount of system maintenance as staffing changes, i.e. we don’t want to have to go in and change every single workflow every time we hire a new employee.
I think the other comments are mostly self-explanatory/quality of life issues, but if you need any further feedback, don’t hesitate to ask.
Can you expand on this?
Absolutely. We have a fairly large technical services department, so envision that the number of people creating the workflows to be s relatively small subset of the staff, so let’s say 3 people. Those 3 people would have the training around the workflow module, and the other staff members would submit requests for features to be implemented. One of the three would then go in and create the workflows requested.
Some examples:
Cataloger A wants to set up a workflow to function as a macro of sorts, so whenever that cataloger does a step, some other thing automatically happens. So, I would need to be able to set the trigger to respond only when Cataloger A meets the trigger requirement, not Anyone or Only Me. You specify those as the 2 options around the 4:00 mark
Let’s say we have graduate students working on a special collections cataloging project for us. We want to set up a workflow that says whenever someone with the role ‘Cataloger - Intern’ creates a record, it goes into someone’s to do as a task to review. This brings in the proposed functionality I mentioned in my previous post.
Essentially, we see this app as being more specialized in nature, especially when it gets into the scripting, so not everyone would be creating these workflows themselves. Therefore, the limitations in our selection options you point out at 4:00 would be a major hurdle for us.
If we can/will create our own Steps; how granular do the out of the box steps need to be? I would like some more info on the questions you are asking of us.
I’m e-mailing you a spreadsheet with some more possible use cases (similar to what Steve Brown just sent). I can try to copy the information here as well if others want to see it.
If/else and loop would be very meaningful to a lot of my work
Triggers I can envision wanting: date related (e.g., quarterly retrieval/editing/loading of records); internal action-related (e.g., when the next issue of a journal is received); external action-related (e.g., new records are available on an external ftp server)
Performing a search and saving the results in a file that can be manipulated (is that a number of steps combined?)
scripts: yes, yes, yes, and yes – this is very exciting (and makes me want to learn to write script)
essential – sharing knowledge, expertise, and practices not only saves time but helps us all think through what we’re doing and why
essential (same as above)
my initial response to this was basically “wow” (“wow” in a good way) (have you seen the systems we work with now? none of the tools I currently use, even those I love and wax poetic about, can do what you’re proposing here)
This is the crux of why many of us are involved with FOILIO at all. The ability to create Macros and Scripts are industry standard for many library tools (i.e. Connexion, Coral, etc.). We can’t rely on library IT to do all the heavy lifting, nor do we want to. Library TS departments have been innovating technology for efficiency since before the typewriter was invented. This is an new path to continue innovation of library work.
Both of these are vital to the library community. We have always worked in a shared tools and systems environment. Duke is committed to continuing to participate in our community in these ways.
Keyboard commands to create/import/edit workflow components are missing. Also the ability to assign tasks/steps to a role, or group of staff members, is also missing.
I agree that capturing productivity, based on KPIs, as well as the time each step takes the staff member to complete a task is very important to management review of the overall processes. So we can tweak expectations as well as workflows.
work in progress, will be updated
How granular should steps be?
— it’s difficult for me to think about this because I am not active working with an ILS. More generally the steps should be as granular as they could be.
How meaningful is it to have logic related steps like if/else and loop?
— having some kind of logical steps seems very important to me.
Which triggers would be meaningful for your work as an individual and for your particular group at your institution?
Which steps would be meaningful for your work as an individual and for your particular group at your institution?
— import/export functionallity; batch processing;
How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
— Perhaps this feature is not needed to be in V1. In general this function looks really powerful.
How meaningful is the ability to publish workflows for others to download?
— I like the social approach to this publishing workflows and scripts. However workflows differentiate from library to library. There should be a granular rights management for deciding who can add workflows to FOLIO.
How meaningful is the ability to publish scripts you write for others to download?
— This looks useful, I just have some concerns when a library imports scripts from the shop. Could there be malware in the scripts?
What’s missing from this prototype?
— assign workflow steps to a group of staff
What works well in this prototype?
— recording steps by doing them in FOLIO; the simplicity of putting together all the steps; automate repetitive tasks
I was thinking more about steps in general; if you are going to make use of a system like this, how granular would the steps be (the ones that come with the system, and the ones that are custom made)?
1. How granular should steps be?
As long as there is customization possible, and flexibility in how much granularity is needed for a particular workflow, as much granularity as possible is welcome.
2. How meaningful is it to have logic related steps like if/else and loop?
This would be a great feature. There are a lot of different directions workflows can take depending on a variety of situations.
Sample workflow at Lehigh University
Cataloging New Print Materials Workflow.pdf (169.2 KB) - This example may help to demonstrate the value we would find in the if/else feature you demonstrated.
3. Which triggers would be meaningful for your work as an individual and for your particular group at your institution?
Some examples of triggers:
A section of the print collection needs to be withdrawn.
A section of the print collection needs to move from one building to another.
A faculty member requests a purchase of an ebook.
An ebook subscription package has been purchased.
4. Which steps would be meaningful for your work as an individual and for your particular group at your institution?
Steps of actions that need to occur inside and outside of FOLIO, would be good to be include.
Examples of steps for the trigger “An ebook subscription package has been purchased”
The license or terms of the purchase is recorded.
The titles in that package subscription are identified.
The system is checked to make sure these titles have not been imported already by someone else at some other time.
The titles are imported into the system with identifiers to show the terms of the licensing.
The availability of this new batch of titles is “published” somewhere. This could mean a group of staff are notified, or the list is pushed out to the discovery layer so patrons are aware of this addition to the collection.
Statistics of this purchase/upload are stored appropriately: How many titles were part of this subscription? ; How much use are they getting at any one point? ;
5. How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
This is great. Keep it.
6. How meaningful is the ability to publish workflows for others to download?
This could be a great time saver. While workflows will differ from institution to institution, if another copy can be downloaded then uploaded and customized, it would probably get heavy use.
7. How meaningful is the ability to publish scripts you write for others to download?
Same as above.
8. What’s missing from this prototype?
I’m not sure if the workflow is visually ‘friendly’ enough for everyday staff. How easily can we see the stage at which a large project with many complex steps is at any given moment?
9. What works well in this prototype?
It seems like it has a flexibility and customization possibilities, which is essential since workflows vary from institution to institution
Overall, I’m very excited about the possibilities that you’ve presented with this prototype, Filip. I agree with many of the comments above concerning the need for as much granularity as possible to improve flexibility, and the usefulness of if/else loops, triggers and especially scripts. I also want to +1 Naun’s comments regarding “what’s missing” - I think it would be great to have some workflow tracking built in that can help us identify bottlenecks or other problems in our processes that may need to be addressed.
In order for me to provide what I hope will be some useful responses, I need to take a step back and delineate the different kinds of work that could potentially be accomplished through the workflow application. Then I can give more feedback on the specifics of each.
Based on our conversations, the demo video, and my understanding of library needs, I believe that there are four potential functions for the workflow app:
To my mind, these seems like four very different things.
I am comfortable with the first three, far less comfortable with the fourth.
I’d assert libraries’ need for workflows is driven primarily by two changed aspects of our work:
With physical resources, the appearance of an item in a work area prompts action for that item. Book trucks move around the library, and the arrival of the cart, or the presence of an item on a particular shelf, indicates that a specific task is required — the book needs to be received, or cataloged, or labeled, or shelved. With an increasing number of our resources being electronic, we have lost many of those signals — many resources never “show up”, so we need something to remind us that action is required.
With e-resources, there are often multi-threaded processes — particularly in selection and licensing — that are both decentralized and running in parallel. All of these processes need to be tracked and come together at specific points in the workflow — e.g., I can’t finalize the purchase of an e-journal package until I have final pricing, approval by the E-Resources Committee, and legal approval. This is a bit different from much of the asynchronous work that traditionally takes place around physical resources.
The alerting workflow seems like a fairly simple process — based on status, time-in-status, and/or operator, notify a person or group of people. Examples would be:
These alerts are really like mini-reports — find stuff that meets these criteria and show me the list so that I can act upon it. (I’m not suggesting that this be implemented with reports; it’s simply a useful mental model for me.) Filip’s demonstrated a UI that allows easy navigation from the to-do list to the place where you can actually take the necessary action, which is essential. (I do think that we need to see more in the prototype regarding how workflows and to-do lists are configured and managed for groups; from experience, this can get tricky.) From a variety of conversations on this topic, I believe that this is still the primary interest, the primary use case, when librarians talk about “workflow management”.
The second function also seems fairly straightforward: what are the conditions that must be true before the next action is taken? For example, before an invoice for a licensed resource is approved for payment, the license must be signed by university counsel. Or, a more complex example: before a purchase decision is made on an e-resource that costs more than $X, trial feedback must be gathered, an initial review of license terms completed, and final pricing available. Resource Management is the area that seems most likely to benefit from this function, particularly in the selection/licensing/purchase processes. From conversation today and in my past product management lives, it often sounds as if a review checklist would be sufficient to address the requirement — the system doesn’t necessarily need to enforce any rules, but to simply present the steps and the status of each, from which a staff member can draw appropriate conclusions and take appropriate actions. I’d be really interested to hear thoughts on this — do we need to enforce the workflow rules, or simply provide them as a guide?
My third understood use for workflows is in codifying business logic to automatically execute specific tasks. I need to think about this one a bit more — I find a lot of appeal in the idea of being able to create automated processes without having to call upon the systems department for support. I might expect to find an automated update of patron data to be managed within Resource Access and automated EDI loads to be configured it Resource Management, but I suppose it could just as easily (maybe technically more easily) be handled in the workflow app. I do think that we need to be careful about conflating automation with workflows, though, as I see them as two distinct (but potentially related) things.
Finally, it’s the last area with which I struggle. Is the intention for the workflow component to define the UI behavior? For example, can a library customize the out-of-the-box UI via workflows to insert an additional step in the circulation check-out process — e.g., to require the user to take a photo of the patron before continuing a transaction if no photo exists? So I scan the patron’s barcode, and rather than going directly to check-out, a rule I’ve set up in workflows instead causes the UI to display the photo capture screen and functionality. (A related question: if your workflow is to add a barcode to an item on receipt, is that a workflow step defined in the workflow app, or an option in the ACQ app?)
If this deep, seamless embedding of workflow is the intent in FOLIO, if the end goal is to give libraries complete customization of the functional components within a workflow and within an interface…I’ll be frank and say that I’m not a believer in this solution for libraries. Not only is this kind of system more expensive to build, it would be more expensive and time-consuming for libraries to implement, since every workflow would have to be defined. (Just as you can’t be half pregnant, you can’t be half workflow-enabled in these environments, unless they’ve changed significantly since the last technical evaluation in which I was involved.) And given the relatively modest workflow support requirements of libraries, which mostly fall into categories 1 and 2 above, I’ve always said that this kind of solution is like using a sledgehammer to hammer in a finishing nail. It’s a cool concept, and it works well in certain types of applications…but I’m skeptical about what value libraries would really gain from this sort of solution.
I totally realize that I haven’t answered most of Filip’s questions, but I think it’s essential that we have a clear understanding of the problems we’re trying to solve and some cost-benefit analysis to determine how robust the solution needs to be for each. Maybe it’s just that I’m coming to this late in the game, but I haven’t seen some of this discussed in depth…and given the potential costs involved, I’d propose that this is a crucial conversation to have before we go too much further.
Thanks for “listening”!
How granular should steps be?
OK, the flip answer is “as granular as they need to be.” Basically every task that cannot be broken down into smaller tasks or every decision point that would result in a different action/next step depending on the decision.
How meaningful is it to have logic related steps like if/else and loop?
It seems like you will need some if/else logic to define the triggers, and maybe to drive different actions. Maybe this would come in v2? If included, will be very important to include examples and help, so that libraries can understand how to use the logic.
Which triggers would be meaningful for your work as an individual and for your particular group at your institution? This could be an interesting brainstorming discussion in each SIG. Here’s a few that come to mind, in absolutely no particular order, and definitely not comprehensive.
a. Time-based, definitely. If this is the only way we’ll be able to schedule/automate title loads or running reports on a regular basis, this will be an important trigger.
b. Task field is changed - does that mean a task is completed perhaps? I can see having a number of checklists, where several tasks have to be completed before someone can move to a next step.
c. Record field is changed
d. Order field is changed
e. Some field in an order record exceeds a certain date or price, or has a certain value
f. Some field in a metadata record (or across all metadata records) has a certain value
g. A new file is has been picked up and is ready for import into FOLIO.
h. A new file has been created (in some format) and is ready for export from FOLIO.
i. An order is cancelled (do I want to notify the requestor that it was not received, or search for a different version to order?)
j. An ordered title is received, and now the piece needs to go through cataloging & shelfready processing.
k. An ordered title is received, and that receipt needs to trigger something else to happen (notify the requestor, weed the previous edition)
Which steps would be meaningful for your work as an individual and for your particular group at your institution?
a. Scheduling will be an important part
b, Automating imports and exports
c. Automating connections to external systems (e.g. open an OCLC session and log me on; open a GOBI session, log me on, and search for an ISBN, etc.)
How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
Maybe for version 2. It seems like we should come up with some use cases before investing in this.
How meaningful is the ability to publish workflows for others to download?
I think this could be very helpful - as a way to start with some defaults. If some library has figured out something complicated, far easier to borrow and adapt their work instead of starting from scratch again.
How meaningful is the ability to publish scripts you write for others to download?
TBD.
What’s missing from this prototype?
It seems like you’ll need a couple levels of dashboards - what do I need to do, or what does my department need to do? If I’m a manager, a dashboard that shows me the outstanding/stuck work in my department or for individual staff. And then eventually some metrics and analytical capabilities - what are the most time-consuming steps? Where is work getting stuck? Is work having to double back because it wasn’t completed properly the first time? Is there a particular staff member who pulls the work from a work queue 90% of the time, and other staff who almost never pull the work?
What works well in this prototype?
I think the scheduler will be especially helpful, if this is the only place in FOLIO that you can define a scheduled/repeating task or workflow. Being able to push work to a unit or person, and then being able to keep track of what has or has not been completed. Being able to get ideas and starters from other libraries in a workflow store. Being able to record repetitive tasks/keystrokes and building shortcuts for those.
Thank you for your honest advice, Kathryn! Keep it coming! We can only build a useful system if everyone shares their thoughts, opinions and experiences, so I appreciate you taking the time to share your thoughts!
Doing a workflows app that can do a few things automatically to begin with, and in which the users can adapt these automations, does not keep us from building logic inside individual apps. However if we do not consider the technical implications of wanting to allow automation in the future to begin with, it will be very hard to build it in later on, as I understand it.
The notion that all things must exist as workflows or none must, I am not sure I understand? Why would we have to make everything a workflow?
In libraries today, automation tools and custom hacks are being used to accomplish a lot of automation and tweaking. I see the Workflows app as a natural way to optimize those tasks instead of building the system without it and then wait until someone figures out a way to hack it, as it is being done with existing systems.
In regards to your questions on enforced behavior for manual tasks, I would advocate that anything performed outside the system should not be attempted verified by the system. In general anything that is assigned to a person should be able to be approved by a person. Anything assigned to an automated process would have a different logic.
Can you expand on this?
Thanks for following up on some of these issues, Filip. Understanding a little more of your view helps me understand scope and intent better!
You did ask about the all-or-nothing comment I made on workflows. As we evaluated workflow engine support in previous projects, my understanding was that they were basically foundational technical infrastructure. That is, every function had to be built as a workflow component, and those components could then be strung together (either in an off-the-shelf solution or a library-defined customization) to create the UI/workflows.
Not sure if that helps to clarify…it’s been awhile since I looked at this stuff, and it’s possible that my memory isn’t as sharp or that technology has changed (or both 
).
OK. My impression is that it is possible to have specific logic in apps themselves, but to have similar logic — logic that is used in multiple apps — implemented as a generic workflow app (like scheduling certain actions on a recurring basis, or assigning tasks to people automatically based on system actions, etc.) . The workflows app will, as I understand it, not be built containing all of this functionality, but rather organize and coordinate assignment of tasks and automated actions that is contained in other apps.
@Sebastian_Hammer and @jakub, perhaps you can consider Kathryn’s thoughts and see if it has impact on what we’re considering with Workflows currently. If we have a discussion about this at this point in time, can we move it to a new topic or some other communication channel, as I would like to keep this Discuss post still focused on UX ideas and advice, and not turn into a technical assesment or discussion. Thank you,
In general, the use cases for Workflows we have been looking into so far has had a very limited scope in the way it reflects in the UI, only controlling the To-do items (tasks assigned to people; what you refer to as check lists or mini-reports), as well as sending notifications to end users. In the To-do app we can potentially show relevant forms to fill out in relation to the items on the “check-list”, but it’s all contained in a view meant for that purpose.
The above example with prompting things to be done when certain things happen in the system, is not something we have thought of or discussed, and I am not sure how one would control it (from a UX point of view, it could quickly become unmanageable). We have had a few discussions about e.g. being able to control fee assignment sequences / logic in a workflow (assign fine when book is overdue, then wait 7 days, then assign and another and send an email reminder, then block patron account and send another email, etc.), but we have not made any conclusions on whether to do that particular use case.
How does my explanation above fare, in terms of helping ease your concern — if at all?
Very helpful and reassuring…thanks!
Slightly off topic, but on the subject of sharing these workflows in a store, the store would need some kind of review/comments section and perhaps even vetting (but by who?) so that institutions could determine how well a given workflow works for others before choosing it.
How granular should steps be?
I agree with Michael’s “Ideally, as granular as any function that an operator can employ - that is, if i can do it on the screen, i should be able to have a step as granular as that.”
How meaningful is it to have logic related steps like if/else and loop?
I think this logic would be applicable to a lot of processes that we would like to automate.
Which triggers would be meaningful for your work as an individual and for your particular group at your institution?
I met with users in circulation, cataloging, and acquisitions to identify triggers/steps that would be useful for them. It is not an exhaustive list, but an initial sample. I can reach out a second time if you’d like more examples. Also, let me know if I am not interpreting triggers or steps properly for our examples. @LauraW is preparing a similar spreadsheet with a few more examples. I am emailing the spreadsheet to @filipjakobsen since I am not able to attach it here.
Which steps would be meaningful for your work as an individual and for your particular group at your institution?
See spreadsheet.
How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
Scripts would be helpful, definitely for our e-resources cataloger, and probably for others as well.
How meaningful is the ability to publish workflows for others to download?
This would be meaningful…especially if the downloading library is able to modify the workflow to fit their institutional needs (add a step here, redefine a destination there, etc.) and then resave it.
How meaningful is the ability to publish scripts you write for others to download?
What’s missing from this prototype?
In addition to the “New from Scratch” option, perhaps a “New from Existing” option as well, in case you have a number of similar workflows where the process is largely the same, but one or two steps get changed based on a criteria (user type, resource type). This would tie into my answer in Q6 above where I’d want to modify the workflow that was downloaded from the store.
What works well in this prototype?
The existing functionality looks great.
The steps need to be very granular in order to capture all of the triggers that may occur across all of the library data, and across all of the various roles of the FOLIO user (staff member).
Can you expand on this, @JacquieSamples, and perhaps mention a few examples that illustrate why you advise as you do in this matter? That makes it easier to make sure I do not misunderstand what you are saying, and therefore more likely that we can work towards something that is useful in practice
The following responses are from Christie and Natascha at UChicago.
They should be flexible enough to accommodate simple and complex workflows as well as staff with varying levels of responsibility and skills. For instance, a student worker and an experienced staff member may perform the same task but in different ways or require more or less guidance. Also, automated workflows would need a high degree of granularity and specificity that manual workflows would not require.
We think they would be required for automated workflows.
The ability to schedule a workflow via a trigger would be important for automated tasks. (E.g. Execute this workflow every day at 8 am.)
It should be possible for the completion of one workflow to trigger another workflow. (E.g. A bib record changing from minimal to full cataloging should trigger either automated or manual review of the record to determine if it meets local criteria for full cataloging. The record could be sent to a workflow for manual or automated review.)
The ability to create a list of objects (e.g. a list of scanned barcodes or the results of a query or search) and either send them to a workflow or create a workflow that is specific to those objects would be useful.
It should be possible to set a threshold or limit so that an action or change must occur a specified number of times before the workflow is triggered. (E.g. Issues of a serial would only be sent for binding after 4 issues have been checked in. At that time all four unbound issues should be pulled for the binding workflow.)
It would be useful if we could create complex triggers that require a number of conditions to be met before an object is sent to a workflow. (E.g. A bibliographic record for an item in a specific location is completed, but an expected 5xx field is not present.)
We would find value in the ability to create a list of local rules to evaluate a set of records or objects against as part of a workflow. For instance, we would like to set up an automated workflow to evaluate the quality of batch ingested bibliographic records and send them to another workflow (or workflows) for correction if they do not meet the local criteria. How could this be done via the workflow app? Would it be possible to reference a set of local business rules in a step? Or, would it be possible to create a series of steps to reflect all of the conditions that must be met? (In which case, it should be possible to embed another workflow as a step.) Or, would this scenario be better served by complex triggers that require multiple conditions to be met?
Would it be possible to embed triggers in a workflow as a step? For instance, a system check of a call number at the point of assignment could trigger an alert if it is already in use on another record.
Will it be possible to have a mix of automated and manual steps in a workflow?
How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
How meaningful is the ability to publish workflows for others to download?
How meaningful is the ability to publish scripts you write for others to download?
We think that all of the above (nos. 5,6,7) would be useful. Even if workflows are institution specific, they could be used as guidelines for developing local workflows or processes.
Workflow management. Supervisors should be able to assign workflows to individuals or specified groups within the library. Progress on workflows could be monitored to allow individuals to know if someone else is already working on a task / workflow, how much progress they have made on a workflow, or which workflows have a priority.
The drag and drop interface is easy to use. The recording function could be really useful.
UX questions to consider — feel free to comment on discuss with your ideas, advice, questions
Hopefully, users of the system would have the ability to choose varying levels of granularity, as appropriate. High granularity is particularly important for automated workflows.
The option to use logic related steps, particularly in automated workflows, would be helpful. Also, there could be some manual workflows that might require different options depending on circumstances.
Again, triggers could be quite helpful. One example might be if FOLIO were set up to process new orders placed by library staff in Gobi (a website for ordering books) automatically until a certain percentage of a fund were spent. Instead of manually creating purchase orders and other acquisitions functions, it might be interesting to see if some routine and highly repetitive work could be automated in FOLIO, but with appropriate triggers sent to staff before any risk of overspending might occur. Of course, one could also envision triggers in FOLIO which would alert staff of a new order placed so they would know that various steps in acquisitions and cataloging/metadata and/or tracking in a knowledge base might be required.
Finding a way to further automate batch processing and other steps required in handling updates for large e-resource serial packages might be helpful.
For some tasks, e.g., batch processing this could be quite helpful. Editing large groups of resource records at once is something that most libraries already do in a variety of systems, but adding scripts to workflows might enable staff with limited IT skills to handle more complex work.
The primary benefit of workflows is at the institutional level, but a “workflow library” that would enable libraries to share highly developed workflows and scripts with other institutions would also be useful. It might make sense to develop a workflow library separately from the larger app store for FOLIO, albeit with the ability to link back and forth as needed. One would hope for the ability to set different permission levels for workflows within an institution as well. This would mean that depending on the kind of work and responsibility performed by individual staff, they might have no access to a particular workflow, view only rights, or view/edit privileges. Likewise, it might be helpful for libraries to share workflows with only one department, the entire library in which they work, other libraries in a consortium, or with the world at large. Depending on the overall level of functionality and importance of workflows within FOLIO, one would hope for a high level of granularity in setting up access and editing privileges.
How meaningful is the ability to publish scripts you write for others to download? This could be most helpful, but please see my answer to question 6 above.
What’s missing from this prototype? FOLIO as a system is going to be most useful as long as it is highly flexible. Workflows could be a great feature, but one would hope an optional feature in that if something has to be done quickly and a user knows exactly what they are doing, e.g., editing a specific mistake or adding a brief note to a purchase order, there should be no need to use a workflow. From my perspective, the greatest potential of the workflows lies in automation and reducing the need to handle large amounts of highly repetitive work manually.
What works well in this prototype? As others have mentioned, the drag and drop interface and recording function.
e.g. “If this incoming file of MARC records is missing a key 9xx field needed to build the item record, then output the records to a review file for further maintenance, else allow the file to proceed with the regular loading process.”
Thanks,
A-M
I agree – that sounds like a good idea. Similar to ratings/reviews in the iPhone app store.
A-M
I see great potential with this interface as a reports middleware or framework - depending upon whether one could create a step making a data query against the data store. For reports there is a need to be able to make ad hoc reports as well as schedule regular reports and to create reusable reports.
For example, one might want a report of all charges in the system more than one month overdue. The report would output user data, item data and charge data. Regarding input selections, one might wish to select against some attribute of user data like user profile “undergraduate” or user status “graduating” - or use a date range to isolate records of users graduating in less than one month time.
It would seem one could leverage the scripting component to make the data calls. But if common objects like “users”, “items”, “charges” could be presented in the UX (with their attributes) and Input and Output selections enabled - then you have a report interface; and those who don’t know scripting could use it. Hope this is on point …
I’d suggest using staff roles and/or permissions for this.
Also . . . while this could theoretically be used to trigger notices or generate fines, I think that these are complicated/specific enough functions that they would need a separate interfaces. We could then use the workflow engine to handle only exceptions.
I agree with this last comment, Andrea. I think this would be best used, as Cheryl put it, as an override sort of function for us. As we in access services know, we are the function of exceptions. I would like a system that had basic functions, such as fines and fees and notice generation, coded into it. This workflow app could then be used for those pesky exceptions that come up. YOur example of the ILL and recall is a perfect example of what this could be used for.
The power of triggers and steps seems directly related to the level of detail by which one can access (and output) records, processes and systems. With a trigger like “item changes status” for example, one would want to specify a delimiter of item status like “lost” and then perhaps only “lost” items in a specific date range and then only items at a certain location.
These may be meaningful for a technical user and the app should be powerful enough to give technical (and non-technical) users a workspace to manipulate the system in creative ways.
In circulation we need access to ALL records of users, items, charges, bills, requests, etcetera, and we need to select these by ANY attribute and we should be able to EVERYTHING by way of triggers and steps we might do at the workstation.
For example, we may wish to select all users who have an attribute of “graduating” and who have outstanding charges and send them a notice about this situation. We should also be able to output a report based upon these selections and actions and be able to specify the datapoints (USER:name, :email, :UID, :status, :library, CHARGE:ID, :due date, :notices_count ITEM:ID, :title, :author).
Also, in relation to building interdepartmental workflows it would useful to be able to create customized item status and select/alter those in the triggers/steps.
The most immediate need is for a interface to build and store reports. So any steps or triggers which allow us to select and combine data is most important.
This is potentially very powerful. It should be incorporated if possible.
Very meaningful and relevant to the vision of FOLIO.
Very meaningful and relevant to the vision of FOLIO.
It would be nice to be able to “run now” on a step or group of steps or entire workflow. If there were debugging information as part of a testing function - that would be ideal.
Please see the comments by Christie and Natasha of UChicago for examples of how workflows might be used at the University of Chicago.
8.? I don’t know if this is meaningful to others. I don’t work with day-to-day workflows. However, I think it would be useful to organize the workflows UX to separate the different kinds of functions it seems to allow. I see automating filling in forms or screens, triggering reports, creating tasks and running custom scripts as rather different things. The separation might be as simple as the ordering of the tasks and steps.
Can you expand on this?
@Kristen_Wilson, Thanks for the comments. What do you mean when you write “edit workflow instance”?
@filipjakobsen I’m thinking of a case where you start a new workflow for a resource based on a “global workflow” – i.e., the workflow you’ve defined in the workflows app. But for for a particular use of the workflow, you need to make a few tweaks. I gave the example of a new resource purchase where the default workflow includes negotiation of a license, but later you come to an agreement with the publisher that you don’t need it after all. You delete the license workflow steps from the workflow instance – but they’re still part of the global workflow. Hopefully that makes sense. My questions are basically asking how you make this change. In the example I gave, do you find and edit the workflow instance from the resource record you are purchasing? Are there some controls that allow you to make the changes?
Hope that makes sense.
As long as the system does not make it mandatory to use workflows or use
specific workflows in sequence, there should not be any problem. Sometimes,
corrections have to be made to records after initial work has been
completed. Also, special projects or unforeseen circumstances may require
different approaches that must be undertaken quickly. Essentially, I am
hoping that workflows can be used when it makes sense to do so as part of
routine operations, but can be bypassed when needed. Please let me know if
this helps?
Thank you,
George