WiscWeb CMS - Defining and working with Content Workflow
Content Workflow can be defined globally for all pages within a site, as well as for specific aspects of the site. This document provides examples of defining workflow both globally and non-globally.
Defining a Global Content Workflow
In this example, we will set up a global content workflow to require users' content edits to be approved by Administrators prior to being published.
Browse to Administer Project Structure > Project.
In the Action Menu, click on Define Workflow.
A new window appears which lets you choose between structural and content workflows.
Select Content Workflow, enter an appropriate name, and click OK.
Notice that SmartTree now shows the workflow attached to the Project item.
To create reactions for triggers, click on the content workflow in SmartTree, and in the Action Menu, click Edit Workflow.
The Workflow Designer window appears that shows you the various triggers (middle column) and reactions (left column) for a content workflow. We are going to associate the reaction that requires a Release, with the triggers of creating and editing pages.
Left-click on the Release box in the left-column, drag it over the Page Created box in the middle-column, and release.
A window appears that lets you define the properties for the reaction. Among the properties you define are:
- who can authorize the release
- how many people need to release it
- if it is rejected, who will it get sent back to
- after the rejected page is corrected, who needs to release it
- the escalation time until the authorizer is sent an e-mail notifying them that the page is waiting to be released
Give the workflow a name, select the project group for Administrators, and press OK.
The Workflow Designer page is updated. For easier reading of the diagrams, you can click the Sort Automatically link in the upper-right corner.
Follow steps 5 and 6 for the Page Changed trigger.
Notice that you could additionally add reactions to the triggers that were newly created (Page Released, Page Rejected, Page Escalated), but this is not necessary. This ability simply makes workflows capable of greater complexity.
Also, be aware that once a workflow reaches a trigger that does not have a reaction for it, the workflow cycle is complete.
Click OK to complete the designing of the content workflow.
Having set up the content workflow, users of the site will now have their submitted content changes reviewed by Administrators prior to being published.
Defining a Non-Global Workflow
Perhaps after setting up a global workflow, you decide that for a portion of the site you do not want to require a release by Administrators for page changes. We can then set up a non-global workflow - in this case, we will cause all of the content beneath the Events page to be editable without requiring approval by Administrators:
In SmartTree, navigate to the Events page, and click on its Container named "con_Center_Column." We are choosing one of the structural elements beneath the Events page, because workflows can only be connected to structural elements and not pages.
In the Action Menu, click Define Workflow.
A new window appears, allowing you to choose between a content workflow and a structural workflow. If other non-global workflows already existed in the site, those would appear as options to choose as well.
Click to select a content workflow, give the workflow a name, and click OK.
The workflow then appears beneath "con_Center_Column" in SmartTree.
Because the workflow is empty, and all that we want to do is to not require any approval process by Administrators, our workflow creation is complete. This workflow will override the global workflow's requirement of Administrator approval for edits. We still need it to apply to other sections beneath the Events page, however.
With the workflow selected, click Edit Workflow Properties in the Action Menu.
A new window appears.
Check the box to "Authorize menu item: Inherit to Following Levels," and click OK.
There is now a new option in the Action Menu to "Inherit to Following Levels."
With the workflow selected, click Inherit to Following Levels and click Yes on the following screen to confirm.
On the second screen, you can check or uncheck the e-mail notification, and then click OK.
In SmartTree, you will see that any substructures now have the workflow assigned to them as well.
Now that con_Center_Column and its substructures have this workflow, we need to apply it to other components of the Events page.
In SmartTree, click on the Events page's "con_Left_Column" Container, and click Define Workflow in the Action Menu.
Again, a new window appears, in this case showing both the option to create a new workflow and the option to connect an existing workflow.
Click to connect the workflow that we just created, and click OK.
Follow steps 6 and 7 for the workflow under "con_Left_Column."
Repeat steps 8 through 10 for "con_Right_Column" and "lst_Navigation" on the Events page.
The workflow will now handle changes made within the Events section of the website.
Workflow Limitations for Sections of the Website
It should be noted that Workflow can only be applied to structural elements (e.g. Containers and Lists), which means that you will be unable to specify workflow for some of the items on the Events page itself. For example, users could still change the meta-description or title of the Events page, and the Global Workflow would handle the change instead of the Events Workflow, because the meta-description and title are not located within any Containers or Lists on the Events page.
Essentially, the Events Workflow will not govern any of the information in the "Page Info" menu at the top of the Events page. However, the Events Workflow will govern all of the Events subpages' "Page Info" menu items, because the Events Workflow will inherit down to them. If we had wanted to make sure that the workflow also impacted the "Page Info" item on the Events page, then we would have had to apply the workflow to the "lst_Navigation" element that holds the Events page. However, this means that this Workflow would also impact other pages (Faculty, Courses, etc.) which inherit that Workflow.