Workflow

Overview

Workflow is used to control what users can publish with the establishment of an approval process. Workflow helps control where people can edit, who can publish, who needs to review content before it is published, and who can bypass the approval process. In the context of OU Campus, workflow is both a process and an area of the interface as the Workflow view within the Dashboard, shows the content that is pending approval.

The configuration of the system determines the roles of various users within workflow. Any level user can be deemed as an approver, or be assigned as a member of the group that can bypass the approvals process. An approver can also be assigned to specific content types within a site, or at the site level. Assigning an approver to a user in essence revokes all publishing rights for that user.

Users have different levels of access to functions within the system, inherently, based on user level, as well as by the assignation of access settings, and therefore, see different options, buttons, menus, and content. Some areas of the interface or production targets may not be viewable. For example, users that have access to a page and no other restrictions (such as an approver), have the ability to publish the page and will see the Publish button in addition to Schedule, Submit for Approval, and Expire options in a dropdown list. A user with an approver assigned is not able to publish and does not see the Publish Now or Schedule buttons, but instead only sees Submit. Users who are able to publish can choose to send content to another user, but are not required to.

When implementing a new site or several new sites, it is advisable to plan out the expected functionality in terms of workflow within the system prior to creating groups and assigning permissions. The reports available in Custom Reports can help identify the groups that are needed to make the site function as desired. Even after planning and execution of the plan, the CMS enables user settings and group membership to be easily changed, and for assigned groups to be removed or changed. The basic steps include:

  1. Define the workflow architecture.
  2. Create users in the system.
  3. Set approvers for users who need them.
  4. Add users to groups to control access.
  5. Set site, publish targets, folder, page, asset, and user access settings. Groups can be assigned to settings at multiple levels and enforced according to precedence.
  6. Set groups on editable regions in page templates, page properties, and template control files.
  7. Train end-users on the workflow process.
Workflow Chart

The system allows for as much or as little flexibility as desired. In some cases, it may be desired to force users to always use the DirectEdit link to access the pages to be edited. The alternative is to assign permissions at various levels of specificity, ranging from the site level to the directories housing the pages to the editable regions. Enforcing access through a DirectEdit link limits the number of groups that may need to be created, but it also limits the users’ abilities to navigate through the folder structure to get to pages to edit. 

Approvers

There several things to keep in mind when playing the role of an approver. Once a page is sent to an approver, it is automatically checked out to that user. Other users in workflow might be completely dependent upon the approver to review and publish the page. To this end, the approver has the standard reviewing tools available such as compare, backup, and review, as well as the standard functionality found for publishing, unless another layer of review has been put into place.

Page Actions Toolbar for Page Pending Approval

As an approver, it is prudent to review a page and approve it or decline it in a timely fashion, as there may be a delay in the review cycle or with the publication of pertinent information if the page is left sitting in workflow. Publish options for a page in workflow include Schedule, Reassign, Decline, and Expire.

Enforcing an Approver

Flexibility is introduced into workflow with the ability to enforce an approver or not. If an approver is enforced for a user, then that user must submit any content to that approver specifically, instead of choosing to whom they submit the content. This may also be used when a peer-to-peer review is desired before the page goes to the final approver for review and publication. Then the person to whom the page is sent for review can publish it, rights permitting, or send it back to the original user or the designated approver.

There can be multiple levels of review. This situation allows for additional flexibility within the system and is defined by an approver having an approver. This implements a workflow process whereby more than one user can review a page.

Most access settings within OU Campus are configured with the use of groups. The assigning of an approver, while it can be accomplished at several levels within the system, only assigns a singular user.

Bypassing the Approver

In addition to choosing not to enforce an approver, there are two types of overrides that can circumvent the approval process. One is at the administrator level, as an administrator has the capability to reassign a page that has been sent for approval.

The second override is the use of the Bypass Approval access setting. A group can be assigned to the Bypass Approval setting and members of that group have the ability to publish without respecting the restrictions of any assigned approvers.

Level 0

Any level user in the system can be assigned as an approver and a frequently used scenario is to create Level 0 for the role of approver. The Level 0 is unique among user levels as it includes very few permissions other than publishing. This level is also known as the reviewer or executive level as the user can review, and choose to decline or publish, but cannot perform any of the editing functions. If changes need to take place, the Level 0 user needs to send the page back to the original user to have the edits completed.