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.
- How meaningful is the ability to add scripts you write yourself or get written by e.g. a more technical colleague?
More often, we’re finding that staff users outside the IT suite have the ability to code and think in coding logic. It would be very helpful if they had a way to create their own scripts.
- 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?
Over the years, we’ve borrowed and sent scripts to other universities when we’ve found a similar set-up or report. This would be very helpful.
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.
- How granular should steps be? 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.
- If/else and loop are critical to constructing workflows that iterate over a range of entities and apply some evaluation and/or action to each entity.
- adding scripts extends the workflow engine in powerful ways. libraries frequently have many external scripts that perform operations on the ILS not provided by the ILS software. being able to incorporate these (in some cases, pre-existing scripts) scripts, allows a library to migrate to FOLIO and preserve integrations with other systems that are reliant on some such script.
- sharing workflows would be important for promulgating innovation in libraries. of course, care would need to be taken that scripts are sensible in a complex environment.
- similar for sharing workflows. libraries share scripts frequently for local adaptation. incorporating scripts into sharing workflows would provide a marketplace where libraries could exchange and extend innovations built on folio workflows
- it may be useful to assist the operator by indicating which triggers and steps they are authorized to use (like grey out ones that require different permissions). I don’t see any overall workflow and script management dashboard. a system manager needs to be able to see what workflows exist and who writes and uses the workflow. Need to see what workflows are running or scheduled.
- the drag and drop visual editor is very helpful (particularly if there is some validation process for steps) for seeing the full workflow and where the interactions exist.
My answers to FIlip’s questions above:
- Steps should be fairly granular, but it would also be good to be able to roll them up into larger steps, or to have one available step be to trigger another workflow, so that if there’s a complex set of steps that I want to encapsulate into other workflows, I don’t have to re-create all the details each time.
- Conditional logic (if/then) seems likely to be useful (if this user is faculty, then do this, if they are a student, do that). Looping strikes me as both a bit less useful and potentially dangerous. It’s the sort of thing that could allow a non-programmer to do a lot of damage when they don’t recognize the impact of the workflow they’ve created.
- Triggers that would be useful from a user management perspective: new user is created (to kick of dependent processes), user is made inactive
- Steps: generating notifications, adding notes to user record
- Custom scripts are definitely essential, although the ability to upload the script or the ability to reference it from a github repo would be much more attractive than a built-in editor. I’d also want the scripting language to be able to make external API calls.
- Publishing workflows would be a great option so that libraries can share. The risk there can be seen in the iOS app store: there are a million apps, and you can’t tell which ones work well, and there’s nothing to stop people from reinventing the same wheels 20 times. So, some community convention for curating the workflow store would be a bonus.
- I think publishing scripts would also be a useful function. Especially since it’s a place where one library’s clever solution could be translated/copied/adapted for use elsewhere. People are going to share them regardless; we might as well build a structure to support that so that if the original author makes an update, folks can have access to that as well.
- Missing from the prototype: perhaps more in-depth descriptions/documentation of triggers and steps, available as a pop-up?
- What works well: I like the drag-and-drop building of the workflow
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:
- Some trigger happens, and we want to create a task of reviewing the catalog record for an updated 035 field. We assign that task to the ‘Cataloger’ role, which is defined in our user management module.
- In the To Do app, everyone with the ‘Cataloger’ role now sees the task to review the catalog record.
this is probably where the workflow functionality ends, but the rest would look something like this
- Cataloger A ‘claims’ the task, taking it out of the to do list for the other catalogers.
- Cataloger A finishes the task, and the workflow continues on to the next step, or finishes if there are none.
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.
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.
- Publishing workflows - very important in consortial or any shared setting where you want to make it easy to conform to a desired practice.
- Publishing scripts - ditto.
- What’s missing - would it be possible to use this as a way to capture statistics? Examples:
- How many operations of this type did this unit complete in the past month?
- What is the average turnaround time for this process (i.e. how much time elapses between step 1 and step n)?
- What percentage of tasks of this type are referred from unit A to unit B?
- What works well - appears to be very flexible and allow us to respond to a wide range of situations