Proposed Workflow Framework

[modius]

Folks,

We have been busily scoping out a clever workflow framework for
FarCry. In effect its a tool for building workflow rather than a
specific set of workflow criteria.

The aim is to allow for this workflow framework to be applied to any
content type regardless of origin. And that workflow should be
extensible through the project and plugins in a similar fashion to
webskins.

This work is being sponsored, but the client would like to see the
code integrated as part of the underlying framework and consequently
made part of the standard distribution. We're publishing our workings
to date in a bid to get some community input to help determine its
suitability for being part of core itself.

Workflow framework notes (temp location only):
http://farcry-beta.googlegroups.com/web/workflow-framework.pdf

The PDF notes are kind of the "Cliff Notes" of the workflow framework
and typically come with a verbal explanation of how things all fit
together. I'm happy to elaborate on specifics if people have
questions. Bare in mind this is a phase 1 proposal, with a view to
providing hooks for increasing functionality in future revisions.

Enjoy!

-- geoff
http://www.daemon.com.au/

[Jeff Coughlin]

Geoff,

This looks like a lot of great work so far.

Some questions I have:
* Are we required to still have all 4 steps as minimum? (draft,
pending, approved, delete)
* Are we able to add/remove steps?

Here are requests I've had from clients in the past:
* Send back to Author
* Content Rejected
* Ability to have "Reviewers" (who can vote 1-5 on items, but not
approve)
* Forward to another reviewer or Approver

And the most requested feature I've ever had regarding workflow is
"Workflow Tracking":
* All people involved to receive email receipts during the workflow
process (your item was approved/rejected, Approvers get an email that
reviewer X has reviewed an item, etc)
* People can view reports in webtop to see the current state of an
item in its workflow process (as well as items that have grown stale)

I hope what I've listed above makes sense :)

--
Jeff Coughlin
Web Application Developer
http://jeffcoughlin.com

[modius]

Jeff Coughlin wrote:
> Some questions I have:
> * Are we required to still have all 4 steps as minimum? (draft,
> pending, approved, delete)

Think of status as a state of being. Under the proposed workflow
framework they are not actually "steps" in their own right, instead
they should be viewed simply as states.

DRAFT: a state of being edited/created. All "workflow" tasks occur
during this state.

PENDING: note this is an optional state and you might opt to simply go
straight to approved on workflow completion. An approval point, where
all tasks are complete. It represents a hook that allows all tasks to
be reviewed at once, but only when all tasks are complete. More
sophisticated workflows might use specific tasks to accomplish
specific approval mechanisms.

APPROVED: content is live. No workflow can be attached to a live item.

DELETE: this is not really a state -- its the absence of state :) If
you wanted to activate a delete workflow, you would create an
"editable draft" just the same as you would be changing a content
item. Only when the attached workflow is complete, both the
underlying draft item and live item will be removed from the system.

> * Are we able to add/remove steps?

Tasks are effectively workflow steps. You can have as many as you
like. In this phase they are run in parallel and cannot be
serialised. Future phases would allow you to force steps into a
sequence. However, after much debate and considerable practical
experience, I would argue that isolating tasks rather than sequencing
them is the primary motivator for workflow.

Hopefully that makes some sense,

-- geoff
http://www.daemon.com.au/

[modius]

On Dec 3, 4:41 pm, Jeff Coughlin <j...@jeffcoughlin.com> wrote:
> Here are requests I've had from clients in the past:
> * Send back to Author
> * Content Rejected

Would probably view these two as the same thing.

Effectively if a task is reopened then the workflow developer would
have the option to capture that event and do something. By default
we'd envisage the system would notify the task owner that their task
was reopened.

With respect to commenting and logging, we are removing fqaudit table
and commentlog properties. These will be replaced by a central farLog
logging table that will record all auditable events, including
workflow comments.

onTaskChange() event would be able to alert the owner to a task being
reopened and append the new and previous comments for their perusal.

I'd envisage having default behaviour for this in the framework that
folks could at least copy and past to form the basis of their own task
events. Imagine a ./webskin/types template that sets this default
behaviour that can be overridden as required.

-- geoff
http://www.daemon.com.au/

[Jeff Coughlin]

Thanks for the response, Geoff.

> Tasks are effectively workflow steps. You can have as many as you
> like. In this phase they are run in parallel and cannot be
> serialised. Future phases would allow you to force steps into a
> sequence. However, after much debate and considerable practical
> experience, I would argue that isolating tasks rather than sequencing
> them is the primary motivator for workflow.

The reason I asked is because I've had requests to have an item
approved by person A, then go on for approval from person B (like a
multi-step approval process by department. Example: A content item
first gets approved by a senior staff member, then goes on for
approval from the department head.)

Regards,

[modius]

On Dec 3, 4:41 pm, Jeff Coughlin <j...@jeffcoughlin.com> wrote:

> Here are requests I've had from clients in the past:

> * Ability to have "Reviewers" (who can vote 1-5 on items, but not
> approve)

Presumably once the item has a score that exceeds a certain threshold
it gets approved? Not in this first phase.

> * Forward to another reviewer or Approver

This might be achieved by changing either the workflow instance owner
or task instance owner and firing an "on Change" event to notify the
new owner.

-- geoff
http://www.daemon.com.au/

[modius]

On Dec 3, 4:41 pm, Jeff Coughlin <j...@jeffcoughlin.com> wrote:

> And the most requested feature I've ever had regarding workflow is
> "Workflow Tracking":
> * All people involved to receive email receipts during the workflow
> process (your item was approved/rejected, Approvers get an email that
> reviewer X has reviewed an item, etc)

The framework will provide hooks for "on change" events for both tasks
and workflow. Any notification service could be attached to these
events. By default we will probably keep notification to a minimum,
but obviously this can be tailored to specific content types.

> * People can view reports in webtop to see the current state of an
> item in its workflow process (as well as items that have grown stale)

Workflow instance and task instance reporting is a specific
deliverable. As each task and workflow is planned to be an
independent content item we should be able to provide very detailed
reporting for users.

-- geoff
http://www.daemon.com.au/

[modius]

Absolutely, its a common request :)

Manager Approval -> Branch Manager -> Legal -> Local Voodoo Priest ->
Go Live

Unfortunately, sequential tasks will not be possible in this phase.

If you could prevail upon "approvers" to wait their turn it might
work. But until we allow for sequential tasks is not going to work as
they might want. However, you'll note tasks are held in an array
which is a natural sequence. It is envisaged that future phases might
add a workflow "manifest" that details business rules for the order of
task completion.

In truth, providing more sophisticated rules around task order is
relatively straight forward. Its the issues surrounding failing
tasks, rolling back tasks to a point in the workflow based on that
failure, and/or skipping tasks for updates that has all the
complexity. For example, if I have a 5 step sequential workflow and I
fail step 2 does that mean that steps 3 & 4 need to be repeated?
Obviously "it depends" and therein lies the complexity.

In an effort to reduce complexity sequential task completion is not in
scope for phase 1.

All the best,

-- geoff
http://www.daemon.com.au/