Sitecore Governance: Workflow Fundamentals and Best Practices

17 octubre, 2012

Building your site is just the first step. Keeping it updated and working effectively often requires workflows and governance decisions that can be just as important as decisions made in the design and build process.

Sitecore provides a very powerful and robust governance control mechanism through its implementation of workflow and security permissions. In spite of this, many organizations still fail to get what they want once the Sitecore implementation goes live. Why is this?

There are a number of reasons:

1. There is the assumption that governance will take care of itself once the product goes live.
2. There is a belief that the product’s features and capabilities will solve operational requirements.
3. Governance at a process level has always simply occurred ‘on the fly’ without any thought or ownership.
4. There is a tendency to “over-engineer” governance, creating roadblocks and preventing users from getting the job done.
5. Many companies aren’t completely sure how to approach governance and continue to operate with the new CMS the way they did prior, with limited discussions, collaboration, ownership and accountability across departments or divisions, eliminating opportunities to realize the benefits the CMS can bring.

As a result, companies either ignore governance, or over-think it. By following a few best practices, Sitecore provides an immensely powerful foundation that can meet a corporation’s needs from the very beginning, scaling into a robust framework that can deliver effectively in the most complex of organizations and environments.

The following pages will describe some of the fundamental areas of Sitecore that should be considered when determining your governance model as well as highlight nonlinear creations Sitecore tips, short-cuts and best practices.

Workflow fundamentals

Workflows facilitate content creation, review, and publication. They are comprised of a series of states and actions that the content must navigate before it is published.

States, commands and actions

Workflows are comprised of three different components: states, commands and actions. When creating a workflow, Sitecore does not restrict the  number of components used.

Below is a graphic of a simple workflow:

In the graphic, each if the boxes represents the states while the arrows represent commands.

States

Every item that undergoes workflow must belong to a state in the workflow. An item’s workflow state establishes:

1. Which roles/users have the ability to edit them;
2. Which roles/users are currently responsible for the item content; and
3. When the item is ready to be published

Typically, each state in a workflow is secured to a specific security role. Only users belonging to that security role and having write access to the item are capable of manipulating the content of the item while the item is in that state.

Commands

Commands are used to promote an item from one workflow state to another. A command requires a workflow state as a target. When the command is executes, the item is moved to the targeted state. Common commands are Submit and Reject.

Note: A targeted state does not need to belong to the current workflow. It is possible to pass an item between workflows using commands. See the Branching Workflows selection below.

Actions

Actions are pieces of functionality that are fired as a result of an item moving through workflow. The most common actions are an immediate publication request or generation of an email. However, actions can be created to fire any custom code.

Action can be configured in two locations:

1. On a command. When a command is fired, the action is executed. For example, a Reject command can send an email.
2. On a state. When an item moves into a state that has an action configured, that action is fired. For example, an item that reaches the Published state might get auto-published.

Workbox

The workbox is a summary interface that allows you to see a snapshot of items in workflow, what state in the workflow they are in, and any actions you are capable of taking.

A screenshot of Sitecore’s workbox is included below. In it, you can see that the Home item is in the Awaiting Approval state of the Sample Workflow. Commands available to the user include Approve and Reject. Sitecore also provides a mechanism for mass updates by providing the ability to act upon multiple items in a state via the check-box and then permitting Approve/Reject(selected) in addition to Approve/Reject(all).

In addition to exposing the configured workflow commands, the workbox also:

1. Provides workflow specific RSS feeds
2. Permits the user to open the item in the Content Editor
3. Launches the item into preview mode
4. Exposes the item compare dialog via Diff action

Security

States, commands and action can all be secured to rolls/users in Sitecore.

When working with workflows and security in Sitecore, it is important to note that there are levels of permission required before a user is able to edit an item in the current workflow state:

1. The user must have write access to the item itself
2. The user must have workflow state write access to the current workflow state

These two permissions work in tandem to determine a user’s ability to edit an item.

Additionally, the user must have read access to the workflow itself to see the workflow in the Workbox.

Workflow assignment

When implementing workflows in Sitecore, it is important to understand how workflows are assigned to content.

Unlike item security, which is accomplished by inheriting permissions from items higher up the content tree, workflows use a different assignment mechanism. They are assigned via the item’s template. A single workflow is assigned to a template, for example a News Article template, you are required to create multiple versions of the News Article template if you need different items based on this template to undergo different workflows (one template per workflow).

Branching workflows

There is no restriction on number of states, commands or actions used to create a workflow or how these components are combined.

A branching workflow can be used to bypass or add additional states/commands/actions to the core workflow path.

An example of adding additional steps to a workflow: the Human Resources department requires additional approval states in the workflow. On the editing state a new command could be created and secured to the Human Resources role. When executed, it moves the item into a new HR approval state with its own commands and actions configured. In this scenario, the item as branched from the main workflow into an HR-specific approval process. This branch can be configured to have any number of states, commands and actions, but eventually has a command that points back to state of the main workflow.

An example of bypassing steps in a workflow: an Information Technology content author may require a way to move an item directly from the editing state of the workflow, all the way to the published state. In this scenario, an additional command, Submit for Publish, could be created and secured on the editing state so that only users belonging to the Information Technology role are able to see and execute the command.

When deciding to use a branch workflow it is important to weigh the benefits/drawbacks of using a branching workflow versus creating a new workflow:

1. When creating an additional workflow, there are additional template configuration and assignments to consider.
2. Depending on the number of components used to create a branching workflow, it can become unwieldy to maintain.

Notification mechanisms

Email

Sitecore is packaged with predefined email workflow actions that can be created and configured on workflow states and commands. Email actions allow you to configure the following pieces of information:

1. The To address: A single email address to which the email is sent.
2. The From address: The address that the email is sent from.
3. Subject: The subject of the email.
4. Message: The body of the email.
5. Mail Server: The IP address of your configured SMTP server.

RSS

From within Sitecore’s Workbox, content authors have the ability to subscribe to workflow or state level or RSS feeds. These feeds can be pulled into productivity tools such as Outlook that content authors are already comfortable using. When an item moves into a workflow state, the RSS feed subsequently notifies the content author of its status.

Publications

Sitecore administrators can manually publish the entire Sitecore content tree or a branch of the content tree at any time. Workflow is intricately intertwined with Sitecore’s publication since it ultimately dictates whether an item is publishable or not.

Scheduled

There is an important distinction to understand about workflows and publishing. An item in the final state of a workflow is not automatically published; it is queued to be published. The content will not be live until a publication action that includes the item is fired.

Typically, Sitecore is configured to do a scheduled publish several times a day to avoid heavy traffic times. Once a publication action is made live. If no, the item is ignored.

Immediate

Sometimes it may be necessary for a content author to publish an item immediately. Although outright publication actions are not typically open to content authors, an auto-publish action can be configured within a workflow and made available to users belonging to a specific role.

Content

It is difficult to talk about workflows without talking specifically to content.

Versions

Every time an item enters workflow (ie. Moves from the final workflow state to initial workflow state), a new version of the item is created. Versions afford you the ability to track the history of changes of the current item.

Over time, especially on items that are updated frequently, the number of versions of an item balloons. As the versions increase, the content author experience slows.

Archive

Once an item is no longer current, it is recommended to archive the item rather than leave it unpublished in the content author environment. This reduces clutter within the folders which can lead to confusion and the proliferation irrelevant.

Sitecore has a built-in archive mechanism which completely removes the item from the content author interface and stores it in Sitecore’s archive. Items in the archive can be restored at a later date.

Compare

Sitecore’s content authors have the ability to compare different versions of the same item by using the Compare functionality found in the Versions ribbon or by using the Diff functionality in the workbox. Both locations spawn the same Compare dialog box.

The Compare dialog box, pictured below, allows the content author to choose two versions of the current item to compare. This is useful when in an approval step in the workflow. For example, it can be leveraged to identity content additions/edits when comparing the latest version of the item with a previous version. Knowing the exact content that has changed without needing to contact the original content author directly helps avoid what could potentially be a bottleneck in the workflow process.

Being proactive

It is easy for content in your site to become stale and no longer relevant. Outlines below are several methods to curb content stagnation.

Digital Marketing System (DMS)

Sitecore’s DMS is an analytics tool that generates and reports on wide-ranging visitor information and statistics. Although DMS is not the subject of the current whitepaper, it can be leveraged to identify stagnant content in your site.

For more information on DMS, visit www.sitecore.net.

Reminders

Reminders can be treated on any item in a Sitecore build. By setting a future data in a reminder, an email can be generated and sent at that time reminding a content author to revisit the content.

Publication dates

Have a piece of content that needs to be present for a short period of time? Using the publication restrictions wizard, content authors can manually configure any version of item to be publishable within a date range.

The first publication that occurs after the publishable from date will publish the corresponding item version and the first publication after the publishable to date unpublished the item version.

Validators

Validators are used in Sitecore to promote and enforce content data integrity. They are essential at the field level to make sure your content meets establishes criteria such as ensuring a field has content, limiting a field to a maximum number of characters, confirming the supplied content is an email address, etc. Validators can also be used at the item level to ensure sibling items are not using the same name, the rendered page is XHTML compliant, identifying internal broken links, etc.

You are not restricted to just the validators packaged with Sitecore. You also have the capacity to create customs validators to enforce a custom validation rule you may have.

A well thought out validation layer ensures your content meets minimal requirements.

Listen to your authors

They are the people in your system who are working with your workflow implementation on a regular basis. Statements such as, “I’m unable to locate my item in the workbox because there are too many items listen in each state,” indicate problems with your implementation and may indicate:

1. Your content authors may have write access to items that they shouldn’t. As a result, they are seeing these items in the workbox because they are undergoing the same workflow.
2. You may need to refine your workflows, further reducing the number of items content authors see in a workflow.

In summary, governance is an important but often overlooked item when implementing CMS in organizations. The reasons may be varied but the results are the same—a CMS project that fails to live up to its expected potential.

Sitecore offers a comprehensive set of tools—workflow and security—enabling robust governance in the most complex of environments.

The overall key to success is to start out simply and add layers of complexity as the organisational needs, experience and user sophistication grows.