traffic cop
Too many people under utilize their workflow capabilities.
They create one-way dead end workflows that cannot handle exceptions (what happens if the request form is incomplete?), cannot escalate reviews if someone is out of the office (vacation, what is that?), and cannot route information to users not otherwise listed (Bob should really take a look at this
Don’t think of the workflows as railroads that only connect Points A and Z (and dead end). Rather think of them as city streets with many intersections and a traffic cop at each intersection directing flow.
A workflow step is an intersection with a cop. Sure, it is easy to create a one way street but then you lose the flexibility to reuse that street for anything else, no matter how close (parallel) it may run.
The first step in your workflow has an initial entry criteria – think of it as a toll gate. Establish security and one additional parameter. That is just to see who gets in the door. Security is really your biggest concern here.
Remember though that each step has events (traffic cops) that have a specific anatomy. (see the anatomy of a workflow step in the WF Implementation Guide on pp 88 here: http://download.oracle.com/docs/cd/E10316_01/cs/cs_doc_10/documentation/admin/workflow_guide_10gr3en.pdf)
UCM workflow step event architecture - click for full sized view
That single initial criteria you asked about is the toll gate and once through you have 3 separate opportunities (intersections) to route content. For example, your toll gate might say only cars (no trucks, bikes or pedestrians) can get onto this road.
Opportunity 1 is an intersection with a traffic cop (workflow entry event). This is where you can put some additional filtering criteria. Essentially the traffic cop tells only blue cars to continue and all others to exit. The blue cars continue on.
Opportunity 2 is a round-about with a traffic cop (workflow update event). The blue cars go around and around until something happens and they are told to either exit or continue on or go onto another road. You can count the times the cars go around, count the days the cars have been going around, wait for someone to approve the car, wait for N number of people to approve the car, wait for folks to reject the car, or any other event, trigger or action you can think of. The car either exits, goes on, goes back to where it came from or goes onto another road.
Opportunity 3 is another intersection with a traffic cop (workflow exit event). Only the blue cars that are told to continue on pass through this intersection and the cop gets one last chance to do something to the car (redirect it, tell it to exit, or modify it some way).
Then you are on to your next STEP in the workflow!
As you can tell, the UCM workflow is less about linear progression and more about complex event processing in an editorial review kind of context.
When you think of UCM workflow steps as containers for business logic, rather than simple stages a document must pass through, then the world of complex event processing really opens up to you. For one last technical example, the fact that the entry events evaluates user assignment logic AFTER it evaluates the event logic you put into it means that users in ANY STEP can be dynamically defined. Think about it, you can have a “workflow” with 5 “steps” with documents passing to different people who have to approve or reject at each step along the way. Or you could have a workflow with only 1 (ONE!) step that dynamically assigns a user the first time the document comes in, then, when that user approves, the step loops back to start over with a different user assigned. Do this 5 times and you have achieved the SAME effect with dramatically less code. That means less code to maintain, less to risk breaking and less UCM resources taken up. All of the audit and workflow review history is saved in the WFHISTORY table so your reporting is as good as ever!
