Jump to content

How to Setup a Drupal Publishing Workflow

+ 3
  adfm's Photo
Posted May 27 2010 06:32 PM

When you get past a few people generating content for your site, you're going to want to set up a publishing workflow. This excerpt from Byron, Berry, et al.'s Using Drupal will introduce you to Drupal's Workflow module, which was designed to solve such situations.

When the built-in “published” flag that Drupal provides for every piece of content is unchecked on the node editing form, only users with the “administer nodes” permission are allowed to view the content. That’s enough for some sites, but it doesn’t give our writers and editors as much control as they need. For example, there’s no way for a writer to mark a story as an in-progress draft and come back to it later. In addition, there’s no easy way for an editor to tell a writer that an article needs more work—the editor must contact the author manually.

This problem is exactly what the Workflow module (http://drupal.org/project/workflow) was designed to solve. It allows site administrators to set up predefined steps, called states, through which every piece of content must pass before publication. A complex site with strict legal requirements might need “Editorial review,” “Legal review,” “Executive approval,” and “Ready to publish” states. When a node is in one of those states, only users in specific roles are allowed to move it to the next state, ensuring that the right people give the content their stamp of approval before it goes live.

The selection of workflow states can be done directly during node creation and editing through a new fieldset added to the node form, as seen in Figure 6.7. Along with changing the state, a user can also leave a comment in the workflow log. This way others can see reasons or notes about a change. Workflow also allows users to schedule a state-change for a specific time. Moving a page from “Executive approval” to “Ready to publish,” for example, can be scheduled for 8:00 a.m., even if the VP made the decision at 11:00 p.m. the previous night.

Figure 6.7. Workflow states selection

Attached Image

In addition to the node form controls, Workflow provides a tab to the node form next to the View and Edit tabs. This tab shows the same state and scheduling controls, along with the Workflow History log that tracks every state change and displays any comments that were left. An example of the log is shown in Figure 6.8.

Figure 6.8. Workflow history log

Attached Image

Even more important, the Workflow module can leverage Drupal’s actions. Every time a node moves from one state to another, specific actions can be fired. For example, the legal department could be notified via email when an editor moves a node from “Editorial review” to “Legal review.” When the vice president signs off on a new piece of content, moving it from “Executive review” to “Ready to publish,” actions can automatically publish the node and promote it to the front page.

This combination of tools (Actions, Trigger, and Workflow) allows sites to use complex editorial processes and intricate approval mechanisms. Each type of content can even have a separate workflow. A streamlined process might make sense for blog posts, and a more rigorous approval system might be needed for official content like a site’s “About us” and “Privacy policy” pages.

In addition to Workflow, the Workflow Access module is also included with the Workflow package. It can hide posts from users based on their roles and the current state of the content. In our complex example, only users with the “legal team” role might be given access to nodes in the “Legal review” state.

Hands-On: Creating a Workflow

For the Twin City Arts site, we are going to need a few states for stories to pass through. We will need a “Draft” state for writers to save in-progress work that isn’t ready to be reviewed yet, and we will need a “Review” state once a piece is submitted. Finally, we will need an “Approved” state where the story is published for all to see on the site.

  1. Go to Administer→Site building→Modules (admin/build/modules) and enable the following module:

    • Workflow package

      • Workflow

  2. Then go to Administer→Site building→Workflow (admin/build/workflow). You will see a message that says, “No workflows have been added. Would you like to add a workflow?” To create one, click the “Add workflow” tab (admin/build/workflow/add).

  3. Enter a Workflow Name of “Article publication” and click the “Add workflow” button.

  4. We are brought to the main workflow listing page shown in Figure 6.9, and we can see that our new “Article publication” workflow has been added to the list. At the bottom of the page is a list of content types. We want our workflow to apply to the Story content type, since that is what we use for articles. Click the select list in the Workflow column for the Story content type and select “Article publication.” Click “Save workflow mapping” to save the changes.

Figure 6.9. Article publication workflow settings

Attached Image

  1. We now have a workflow assigned to Story content, but it doesn’t do anything yet. We need to add the various states we want for our articles. Click the “Add state” link. Enter “Draft” as the “State name” and click Save.

  2. Follow the same process, clicking “Add state,” and adding each of the other two states: Review and Approved. Your Workflow list should look like Figure 6.10 when you are done.

Figure 6.10. List of workflow states for the Article publication workflow

Attached Image

  1. Fill out the workflow transitions by checking off the roles, following Table 6.5, as shown in Figure 6.11. Note that we are intentionally not setting anything in the “Approved” row, because once it is approved and published it won’t go “backward” to either the “Draft” or “Review” states.

    Table 6.5. Transition settings for the “Article publication” workflow

    From / To













  1. On this screen, the last thing we need to do is determine who will see the Workflow tab when looking at nodes. Everyone will already see the regular workflow fieldset on the node form itself. Those that have the tab as well will get the added benefit of reviewing the Workflow History log. We’ll set our editors up for that by checking the “editor” role under “Workflow tab” permissions. Click the Save button when you are done.

  2. One final piece still remains: the action that sends email to the editors is still set up to fire whenever a node is saved. We want it to notify editors whenever a node is submitted for review, not necessarily when it is created. Again, make sure you are on Administer→Site building→Workflow (admin/build/workflow) and click the Actions link for the “Article publishing” workflow. This will take you to the Trigger module’s configuration page again, but this time you will notice you are on the Workflow tab.

  3. We are presented with a list of the transitions that we have defined for our workflow. Set the actions for them according to Table 6.6, clicking Assign for each action you add to a trigger. When finished, your screen should look like Figure 6.11. It's also a good idea to remove the actions we assigned on the Node Triggers page (admin/build/trigger/node). Now that actions are triggered by workflow states, we don't need the old ones.

    Table 6.6. Assigning actions to workflow triggers



    When story moves from (creation) to Review

    system: Notify editor

    system: Placate author

    When story moves from Draft to Review

    system: Notify editor

    system: Placate author

    When story moves from Review to Draft

    system: Agitate author

    When story moves from Review to Approved

    node: Publish post


    When you add the “Publish post” action, Drupal will automatically add the “Save post” action, too, along with a message explaining why: “You have added an action that changes the property of a post. A Save post action has been added so that the property change will be saved.” Because we are making a change to the node’s status, that change needs to be saved as well.

  1. Now, if we go to Create content→Story (node/add/story) and create a new Story, under the “Article publication” fieldset we can see that writers have the ability to set the status to either the Draft or Review states, but not the Approved state, as shown in Figure 6.12.

Figure 6.11. Action assignments for workflow states

Attached Image

Figure 6.12. Article publication workflow in action

Attached Image

Go ahead and create a story or two. Set at least one story to the Review state and you should see a message that your story has been submitted for review.

Now if you are logged in as the administrator and visit the workflow tab on a story in the Review state, you can see that you have the additional option to move the story into the “Approved” state, which regular users can’t.

Using Drupal

Learn more about this topic from Using Drupal.

With the recipes in this book, you can take full advantage of the vast collection of community-contributed modules that make the Drupal web framework useful and unique. You'll get the information you need about how to combine modules in interesting ways (with a minimum of code-wrangling) to develop a variety of community-driven websites -- including a wiki, publishing workflow site, photo gallery, product review site, online store, user group site, and more.

See what you'll learn

1 Subscribe

1 Reply

 : Feb 21 2013 02:30 AM

Thanks for the post, everything works fine with the method you have posted and indeed helpful in organizing workflow. The only thing I'm stuck with is at point number 10. I have created some workflow and their respective states and also configured content types to use those workflow. I've configured user role to view/edit specific content types as well. In my site I want to add two functionality..

1. An administrator will assign task to specific user and not to whole USER ROLE. i.e tasks should be assigned to specific users only.
2. Further i want to notify specific users who are involved in that particular workflow about the transition change from one state to another of the workflow.

Eg. Steve is an administrator and grants a task to his student Mark, who is a member of STUDENT role. As the task is only for Mark therefore only Mark (and Steve) should be able to change the states of the workflow and should get some notification about the task granted. Once Mark has completed the task and submitted the post back to Steve he will change the relative state and then, Steve should get some notification (may not be dynamic) about the change of state.

PS. My site is completely offline so I can't send email notification. Also Pls explain how to do instead of just suggesting modules to use.