I'd like to see something in this that allows for parallel workflow so the same object is allowed to be in more than one place at a time, in more than one state. I'd also like to see a graphviz or dia interface to this so the workflow is nicely visualized.

I regularly use the first concept when implementing workflow-using applications, the second is a nice thing I've liked from Lotus Workflow. See a screenshot at Here is a screenshot of something that was created in a Visio-like editor.

Otherwise, nice job. How tied is this to SPOPS or can the persistence layer be swapped for other things? How about sub-processes? Once you have multiple workflow processes running they may need to interact. For example - employee changes process may require a network access request which would have its own workflow which may drive other processes, etc.

Having a workflow in multiple states is one of those features that makes things much more complicated. In fact one of the reasons I created this was because I was exposed to Open Symphony Workflow through JIRA, both of which are Java products. OS Workflow can do the split/join mechanism but IMO it makes the configuration much more convoluted, and this complexity was something I really wanted to avoid.

So my tack was to not include it in the beginning and see what people thought, adding it in later if demand warrants and if we can add it without making things too complicated. I think you're right that it's really useful.

I really dig the idea of a GraphViz view of a workflow. I'll see about that.

Also, this isn't tied to SPOPS at all. (No pun intended...) SPOPS is one of the persistence mechanisms, but you don't have to use it. There are also a generic DBI and a file-based persistence stores as well. If I used Class::DBI there'd probably be one of those, too :-)

Chris
M-x auto-bs-mode

I completely agree with the first paragraph. I help maintain a (Java) web based system with workflow at the core which has a split in the workflow route which allows two teams to work independently on "cases". If we didn't have this situation we would have just built our own simple workflow into the app using flags in database tables.