[Phpgroupware-developers] workflow as a feature in phpgroupware

[Craig Allan]

With reference to the discussion between core development team on
http://www.phpgroupware.org/devteam/wiki/index.php?page=WorkFlow

Workflow systems are *very* *very* useful to most organisations.

If you do want to include workflow, it is not a trivial task. But it 
is possible to put together a low-end system for general use  - the 
hardest part is designing a simple UI which hides all the complexity.

My impression from the page above is that the team is immediately 
leaping to see how it will work technically without first getting the 
underlying concepts right.  It is better (IMHO) to work first on the 
concepts and then code them.

I have been implementing a basic workflow system for my own use, 
mainly to track the aproval and construction of engineering projects, 
using  Linux/Apache/MySQL/PHP.  I provide some of my experience 
below...


MY DESIGN APPROACH

Workflow is a way for an organisation to create an assembly line for 
any process.  Something - we can call it a "Work" object - is fed 
through the organisation and various things happen to it as it moves 
through.

There are three "R" words (in english) that are important.

ROUTES - there is a path which a Work object follows through the 
organisation - this is a route. Almost always the route branches many 
times, with each branch being based on a decision.  There is thus a 
network of routes, which branch (or come together) at decisions - 
Decisions can be seen as objects - I call those DecisionPoint objects.

RULES - these are the basis of decisions made at DecisionPoint 
objects. Some attribute of a Work object is tested, and the Work 
object is then routed according to the result of the test.  All 
routing is to another DecisionPoint object.

ROLES - this is the duty of a human being, and it is associated with 
a DecisionPoint object. The human will apply intelligence to the Work 
object, do work on it, add information, change some of its attributes 
and submit it to the RULES for a routing decision.



Some technical stuff.

Any DecisionPoint is associated with a input queue. This is simply a 
queue of incoming Work objects waiting for a human to do something to 
their attributes. The human who belongs to that input queue will 
process the Work objects according to his/her ROLE, which changes 
their attributes, and will submit them to the RULES side of the 
DecisionPoint which will make a routing decision, based on the 
attributes, and send them off to the next DecisionPoint.

The human should be able to view the input queue, to open any waiting 
Work object, to edit attributes as required and to submit it.  There 
are various details about the status of Work objects in the queue 
which we can skim over.

The input queue should be linked to a notification system, (e-mail, 
SMS, other...) to warn humans of arriving Work objects.

More technical stuff...

It is highly desirable that the workflow system works with a document 
management system. Much of the work the humans do will be supported 
by attached documentation. The humans will want to create, read, 
amend and delete the attached documents.

This requires that the Work object contains pointers that identify 
associated documents. You can stuff documents into binary large 
object (BLOB) fields, but I prefer to leave them in the normal 
filesystem and save a unique resource identifier (URI) in the 
document fields.

Much more technical stuff...

A Work object only has workflow system intelligence associated with 
it.  It does not absorb and integrate other databases.

A Work object can be associated with a huge amount of data. For 
example a simple workflow for a credit check can have links to 
criminal records, salaries and wages, marriage and divorce status 
etc, etc. This information is not part of the workflow system. In a 
sense it is unrelated attached data.  It is data the human will use 
to change one or two attributes on the Work object. Don't try and 
incorporate it into the system - just point to it with a URI.
(If you are designing a huge single purpose system then you can 
integrate everything, but resist the temptation as long as possible.)


Even more and more technical stuff...

An administrator will need to be able to set up the workflow system, 
so there has to be a UI for that. The average user will not be trying 
to set up a workflow.

The adminstrator will want to design the Work object. The object will 
have standard attributes about its status and which queue it is in 
and other system details which can be invisible to users, but there 
will always be attributes which identify the Work object, attributes 
which are changed by the humans, and attributes which will control 
routing decisions.

The DecisionPoint object will need to be designed too. Apart from 
hidden system details, a human must be assigned to it (see Contact 
database for this) and the role of the human must be defined, and all 
the possible routing decisions from it must be defined.


Closing technical stuff...

You need a reporting and tracking system, to search and find where 
any Work object is in the system, to identify Work objects that have 
become stalled in  some queue, to report on throughput, to report on 
productivity of humans, to report on errors and problems...  This is 
not so hard to do - simple SQL queries will meet most needs.