Mark, I think pre-populating the most basic workflow elements upon creation of a new workflow is a great idea. I would take it one step further and allow the creation of "workflow templates" such that whenever a new workflow is being created, you could have a selection of pre-built options to choose from and customize. The "default" one you describe would simply be the first and most basic one. I had also been thinking about a similar concept of "copying" a workflow for use elsewhere. Maybe we simply combine the concepts, and create a "copy workflow" agent that asks which database to look in for an existing workflow definition, then asks for a new name, and finally copies all those documents into the current db, modifying the necessary fields along the way. You would then just need to have a default workflow defined somewhere, perhaps in a "workflow repository" db. Finally, in order to keep track of which newly copied workflow docs have been "verified" or "customized" for their new purpose, some sort of draft/unverified flag might be employed.



This is not unlike the paradigm of creating new Notes dbs from templates or by copying existing ones, but there still are differences to consider. For starters, there are form dependencies that may not be obvious from a cursory look at the workflow documents. Maybe the answer is to include the form note (and other dependencies) in the definition of the workflow so it is copied along with the docs. And there are also ACL Role dependencies, and perhaps even specific names that may be entered in some places, making it hard to share a workflow between companies, for instance.



This last point touches on the possibility of creating a secondary open-source project for workflow definitions using the Qenos framework. I don't know if DXL is mature enough to be used for this purpose yet, but regardless there are ways to do this I'm sure.



Of course, putting a lot of effort into this may be unnecessary, since one can always just copy an existing .nsf, workflow docs, forms, and all, and then customize. If however a single database needs to have multiple, similar workflows, then this becomes much more useful. I suspect this is often the case, so the effort is probably worthwhile.