New workflows in Plone 3

Introduction

Plone 3 comes bundled with a set of new workflows. Each workflow is unique in the way they allow site administrators to manage the content's life-cycle and the process their users follow when creating, editing, reviewing and viewing the content.

The best way to get to know any workflow is to test it with different user profiles, each granted a specific role(s) on the site. When you first install Plone you start by having a single "admin" user profile.

We begin by having two browsers running side by side. I usually use Safari and Firefox, but any combination of modern browsers will work. I'm going to use Safari with the admin account and Firefox with the less privileged users. Access your Plone site with the first browser and login as the admin, then access the site in the second browser and login as an unprivileged user.

Simple Publication Workflow

When installed, Plone defaults to the "Simple Publication Workflow". The description for the workflow definition states the following:

• Simple workflow that is useful for basic web sites.
• Things start out as private, and can either be submitted for review, or published directly.
• The creator of a content item can edit the item even after it is published.

When a new user is first created, the user is only able to edit his profile and manage the portlets that appear on his dashboard. In order for the new user to be able to create content on the site they have to first be granted appropriate permissions. This can be done either site-wide using the Users and Groups control panel under Site Setup or for particular location or folder on the site using the sharing tab. I'm going to grant the test user the "Contributor" role site-wide.

Now, switching to the second browser I'm able to add a page and edit its content. Because, as we saw previously, the initial state is private only the owner user or another user with a manager role can access the page at this point.

Let's add a new, third user and grant her the "Editor" role so we can see how users with different roles may interact with the newly created content in this workflow.

The new user can edit the page and submit it for publication, but not add new content. In the case of this workflow such a restriction is useful for separating the site's users according to tasks they perform. For example if several users are working on creating site content, one can be made responsible for adding content to the site, while another will be able to edit and submit the new content for publishing by yet another user.

Once content is submitted for review, it enters the "pending" state. A "Reviewer" user can send it back to the "private" state or "publish" it. While in the "pending" state neither the "Editor" nor a "Contributor" may change the content.

But either might decide to edit the page once the content is published, if the change is minor, or retract it and re-submit it for review, if the changes are major. This way the simple publication makes the review process mandatory only for new content. Once content has been marked public it is the responsibility of the content creator and editor to manage it and the review process is geared towards an organization with some amount of trust to the respective content creators and editors.

While the content is private only the Editor, Contributor and Reader can access it. This feature makes clear the distinction between what sorts of edits may occur while content is public, and what changes would call for content to be made private and then re-submitted for review. For example a piece of content may describe a line of business products. While minor changes on product pages wouldn't require the content to be made private, a major change in product features would call for the editor of the changes to re-submit the content for review by the product line's manager.

Workflows can be represented using graphical diagrams. Rectangles in a workflow diagram represent content states, while the lines connecting the rectangles represent transitions between the states. The diagrams following each of the sections describing the individual workflow can be used to quickly visualize and evaluate the workflow.

Intranet/Extranet Workflow

• An intranet workflow where content is only accessible if you are logged in.
• Basic states are: Internal Draft, Pending Review, Internally Published and Private.
• Also has an Externally Published state, so you can make selected content available to people outside the intranet.

It is useful to test workflows to see how they fit your individual requirements. You can keep the same browser windows open and the same users, and only have to change the workflow in the "Types" configuration panel under "Site Setup."

Switch to the "Intranet/Extranet" workflow. When switching you will be asked to choose equivalent states for content in the new workflow. When the new workflow is applied the content will be transitioned from the old workflow states to the new according to the mapping you choose.

Try adding content with one user, editing, reviewing and accessing content while not logged in.

An often requested feature is the separation between internal and external content. Instead of having two separate publishing systems, it is possible to apply the pattern with a set of additional states in the workflow.

Thus instead of having a single published state, there's now internally and externally published states. In the first only site members can view pages, in the second anyone including anonymous users can view.

While a page is in the internal draft state it can be viewed and edited by owners and editors and viewed by all members. But in the private state only the owner and members who have been granted the permissions to edit or contribute to the content can view.

Once internally or externally published only a manager user can manipulate content's state and the pages are no longer editable. This encourages a hierarchical review process where a select set of decision makers interact with content producers, editors, and reviewers. This pattern is often found in a print or electronic publication office.

Community Workflow

• Users can create content that is immediately publicly accessible.
• Content can be submitted for publication by the content's creator or a Manager, which is typically done to promote events or news to the front page.
• Reviewers can publish or reject content, content owners can retract their submissions.
• While the content is awaiting review it is readable by anybody.
• If content is published, it can only be retracted by a Manager.

In case your site is dedicated to an open community of members and you don't intend to prevent the public from viewing content while it is still in the process of being considered for publishing, the community workflow might fit your needs.

This could be the case for a users' group site. While all registered members might be trusted to generate relevant content, a select few can be trusted to mark content public. As the description suggests the public state can be used to identify content featured on the home page or in another case the published state can be used for syndication.

One State Workflow

• Essentially a workflow with no transitions, but has a Published state, so portlets and applications that expect that state will continue to work

The simplest of all the workflows is most useful with a personal web application, such as a blog. In the case when only a single person manages the content, she might decide that it is not helpful to have the additional step of marking content public where all content is meant to be public.

Conclusion

With Plone 3 the already rich workflow story has been enhanced to allow organizations as varied as a personal blog and a large publishing office to easily represent their business process in the content management system. Remember that the best way to find the workflow that works for you is to try the different workflows and to find one that closely matches your requirements.