Implementing Web Publishing Workflows

Out of the box, most content management systems provide a very basic publishing workflow that consists of two states: "unpublished" and "published". Although it may be sufficient for a site of a very small organization or a personal web site, most large, mid-size, and even many small organizations will probably need more complex workflows.

Let me show you a very simple web publishing workflow that goes beyond the default "two-state solution". Bear in mind that, even though this workflow may be used in real life as is, being an intentionally oversimplified example for those who are not familiar with the subject, it has its limitations.


Say, we have an organization that employs a bunch of freelance writers, an editor, and a content manager. These will be abstracted in three CMS roles: "freelance writer", "editor", and "content manager". Our workflow states are going to be: "draft", "editorial review", "approved" and "live" (I intentionally do not use "published" in order to avoid confusion of this custom workflow state with the default "published" workflow state most CMS's come with out of the box).

You probably have already figured out how this is supposed to work:

1. A freelance writer creates a piece of content (say, an article). Its initial workflow state is "draft".
2. He/she then submits the content for editorial review, i.e. changes the workflow state of the content to "editorial review".
3. The editor reviews the content and either approves it for publishing (i.e. changes the workflow state to "approved") or returns it back to the author (i.e. changes the workflow state back to "draft") most likely with some feedback. In the latter case the whole workflow starts all over again.
4. The content manager publishes the approved content (i.e. changes its workflow state to "live") or, in some extreme cases, returns it back to the author (i.e. changes the workflow state back to "draft"), in which case the whole workflow starts all over again.

Now, in order to make this workflow work (as opposed to just be a set of "labels"), we need to define three things:

1. all allowed state-to-state transitions (which we have already done above, but we will repeat them again in a more formal and less verbose way);
2. user roles that are allowed to perform each of those transitions;
3. permissions of each user role for each of the content workflow states.

So, let's, once again, list all workflow transitions:

draft            => editorial review 
editorial review => draft 
editorial review => approved 
approved         => draft 
approved         => live 

Note: the ideal scenario, of course, is: draft => editorial review => approved => live.

Now, let's define which roles can perform each of the transitions:

draft            => editorial review 

• author

Note: Yes, "author" technically is not a role, but rather a relationship. Here we assume that a "freelance writer" creates an instance of the content type for which we are defining this workflow, and, relative to that instance, he/she is the "author".

editorial review => draft

• editor

editorial review => approved

• editor

approved         => draft

• content manager

approved         => live

• content manager

Finally, we have to define permissions for each of the roles in each of the workflow states.

Think of a piece of content as a database record with a bunch of fields (say, "title", "body", "author_id", "creation_time", etc.). What can one do with a database record? - CRUD (Create, Read, Update, Delete).

Since we are defining a workflow for a content type, it (the workflow) is only applicable when an instance of the content type exists. Thus, the permission to create a content type instance is not a part of this workflow and should be defined elsewhere (most likely, in the general set of permissions of the CMS). So, in our workflow we only need to define the RUD (Read, Update, Delete) permissions for each of the roles in each of the workflow states.

Let's do just that (permissions that are absolutely necessary for this workflow to work are boldfaced):

draft

• R: author, editor, content manager
• U: author

editorial review

• R: author, editor, content manager

approved

• R: author, editor, content manager

live

• R: author, editor, content manager, authenticated user, anonymous user

Note: Here we assume that
• live content should be available to all authenticated and anonymous users;
• only the author can update his/her content whereas the editor and content manager can only "move" the content back and forth between states;
• live content remains such "forever";
• there is some other role outside this workflow (most probably, administrator of the CMS) that is allowed to delete content.
All of these are just assumptions that, of course, may or may not be applicable in real-life situations.

That's all there is to it. No magic. Again, this is an intentionally oversimplified example meant to help those who are not familiar with the concept of workflows.