Workflow is the series of steps needed to do a task. We need to make sure:

• The task can be done
• The task isn’t too difficult, expensive, or time consuming
• We know how to set up Drupal to support the task

Drupal does a lot, out of the box. However, there are some tasks that require extra work. Download and configuring a module, or even writing a custom module. You need a programmer for the second one. It can get expensive.

So, it’s best if we choose ways of working that we can implement using the Drupal skills we already have.

The most difficult workflows are related:

• Exhibitors apply for a table
• Exhibitors edit their pages
• Approving exhibitor pages

Applying for a table

The sign up process could be fully automated, except there are rules for who can exhibit and who can’t. E.g., no adult content, no weapons. Drupal isn’t smart enough to check for these things, so Sylvia has to do it. Here’s one way to do it.

Below, a “group rep” is a representative of the exhibitor group.

1. Group rep completes contact form, applying for a table
2. Sylvia checks the application
3. If it’s OK, Sylvia creates a user account, and sends the login and password to the group rep
4. If the application is not OK, Sylvia emails the group rep, denying the request

That’s a workflow. Writing it out like this helps figure out whether it would work, and also identify info needed. For example, Sylvia can’t email a username and password, if she doesn’t have an email address to send them to.

Often, workflows are shown graphically in flowcharts, like this:

You can put notes on flowcharts if you want, to remind yourself what’s going on.

Use whatever helps you understand the workflow. Flowcharts, lists, whatevs.

Notice that the exhibition manager creates the accounts. That’s Sylvia. We know that Drupal uses roles to figure out what each user can do. Sylvia can assign a role while creating the account.

Exhibitors edit their pages

We have to make sure that the group reps can do what they need to do. Let’s write down the steps they’ll go through to edit their exhibit page.

• Log in to the Web site
• Go to the list of groups
• Click on your group
• Edit the content
• Save

How will this work in Drupal? Recall that Sylvia creates users for exhibitors. Let’s say a user is darkdojo. When she creates the exhibitor node for Dark Dojo (an node is like a page), she can assign darkdojo as the author of the page:

She can give darkdojo the role Exhibitor:

OK, so there’s a user darkdojo with the role Exhibitor. darkdojo owns a node (page) with the title Dark Dojo. Now, we set a permission to let Exhibitors edit nodes they own:

Exhibitors only own one node: the one for their own exhibit. So darkdojo can edit the Dark Dojo node, but nothing else.

Here’s another way to explain it:

Because	User darkdojo has role Exhibitor
and	Users with the Exhibitor role can edit nodes they own
and	User darkdojo owns the node with the title Dark Dojo
Therefore	User darkdojo can edit the node with the title Dark Dojo

When darkdojo looks at the Dark Dojo page, Drupal will show an edit link. When other users (including Anonymous) look at the same page, Drupal won’t show the link. The exceptions are Sylvia and administrators, who have permission to edit anything.

Approving exhibitor pages

There’s one other thing we need to deal with. Let’s say darkdojo gets an account, and edits the Dark Dojo page. Adds a lot of content. Sylvia is still a bit nervous. Although a group rep might agree to follow the rules, that doesn’t mean that s/he will. Sylvia wants to look at what they did before it shows up on the site.

Every node has a “Published” flag. It’s either Yes, or No. If it’s Yes, the node will show on the site. If Published is No, the node won’t show up on the site. The data is still there, it’s just hidden. From most users, anyway.

We can set things up so that when an Exhibit node is created, it isn’t published automatically. Here’s admin setting up the Exhibit content type:

Published is not checked. So when someone creates a new Exhibit node, it won’t be visible to regular users. It won’t show up in lists, either. This gives Sylvia a chance to check the page before it goes live, to make sure the exhibitor really is following the rules.

We need to do two things for Sylvia. First, we need to give her a list of unpublished Exhibit pages, so she knows what to check. Second, we need to let her publish Exhibit pages that she thinks are OK. We’ll see how to do that later.

Oh, another way unpublishing helps Sylvia. It lets her take any page offline without deleting it. Remember that we have a list of door prizes. We’ll also have a page for each prize. Suppose there’s a problem with a prize, like an inflated retail value. Sylvia can unpublish that page. It won’t show up on the site. It won’t be in the list of prizes, either. Suppose Sylvia talks to the prize donor, and fixes the problem with the page. She then simply publishes it. The page reappears, and shows up in the prize lists.

Roles, permissions, unpublishing… this is what makes Drupal good for businesses. They can set up workflows the way they want.