When designing a customized workflow for a system like Plone, it's usually a good idea to figure out a specific need or question your workflow is answering.

In our case, that question is:  who can see this, and what can they do with it?  Our current workflow was primarily designed for selective disclosure of content, with four basic levels:  private, group, subscriber (site-wide access) and public (everyone on the internet). If an item is published, for example, that means anyone on the internet can read it, our site subscribers can add comments, but only managers can edit it directly.

This access/permissions approach addresses only one aspect of workflow.  In our case, I decided it would be best and easiest to limit our model to answering one question.  

It would also be possible to mix in process aspects of a content development workflow, like brainstorming, or final draft, that would indicate the stage of evolution of an idea, from first inkling to finished project.  Such a workflow might have the following states:

1. Sketch
2. Draft
3. Please Comment
4. Revision
5. Pre-Release
6. Published

In the above scenario, let's say that the permissions are exactly the same for stages 1 - 5: the author can edit, everyone else can add comments.  What's the point of having all of these states?

First, the additional states help users figure out, at a glance, where the item is in a defined process.  In our workflow, an item in 'Group Only' state might essentially be in its final static form, or it may be a draft of a document that will change dramatically and ultimately be published.  Our workflow design does not give any indication of this status using states and transitions, so we add notes to this effect in the description field, or in workflow comments.

Second, the states can be used as search criteria in smart folders to present users all the content items side-wide that are in a specific stage of development. For example, if you are using Plone as an intranet for a writing team, you could have a smart folder that shows only items that are in the 'sketch' phase and need to be expanded into a full draft. Alternatively, the 'review' portlet could be copied and tweaked to present all items that are in the 'Please Comment' state, or to display a list of 'Pre-Release' items to the reviewer group.

Third, scripts can be added to state transitions to execute specific actions related to that stage of content development. For example, you might want to send out an email notification asking for comments when you transition to the 'Please Comment' state.

There are ways to send email on workflow transitions, but setup is non-trivial.  In our case, 95% of our users don't want to be notified of site-wide state transitions 95% of the time, so we do not have a transition-triggered notification system enabled. 

A queueing system, which collects notifications based on user preferences, and sends email at a rate defined by each user, would be ideal. The PloneSubscription product seems promising, but I have not had a chance to test it.