New in 1.12.0

Introduction to Workflows

Website content serves many and varied purposes, and, from our own experience we know that publishing can be a process that asks for regulations or at least agreements regarding not only the information to be conveyed as such but also its accuracy, completeness, up-to-dateness, and readability.

The content presented to website visitors, its wording and tone, its clearness and connectedness contributes to your company’s corporate identity and must, at the same time, meet the visitors’ expectations. Also, timeliness and accountability play an important role in the publishing process. Think of critical pieces of content such as business reports, terms of services, or contract details; you wouldn’t want such highly relevant and legally binding content to reach the public before it has been proofread and approved of, would you? You most probably also want the right team to work on specific content, not just anyone who feels they could do it.

Scrivito lets admins and everyone who has been granted the “Manage users” permission add users and teams to the Scrivito CMS concerned. See Managing Users, Teams, and Working Copy Collaborators for details. By assigning users to teams, you can grant users permissions as well as organize your staff into groups by their expertise, responsibilities, or by whichever criteria you wish to differentiate. You can then take recourse to those teams when defining workflows.

CMS workflows free up time by reducing the effort required to ensure that the proper sequence of steps in the editorial cycle is observed. They enable you to have content creation, maintenance, and publishing tasks accomplished in a productive and targeted manner.

To give you an idea of the basic textual requirements and the business and readership-related demands that come into play when striving to offer valuable content, we’ve carved out several points that may serve as reminders or even as checklists.

TEXT-RELATED REQUIREMENTS AND DEMANDS

Textual requirements


  • Factual correctness and completeness (does not omit relevant facts or aspects)
  • Appropriate scope and focus
  • Appropriate extent and level of detailedness
  • Uses clear, nicely flowing language
  • Consistent regarding wording, writing style (tone, register, explicitness, etc.), and structure
  • Follows the current spelling, punctuation, and grammar rules

Business-related demands


  • Legally not objectionable
  • Relevant and connected to business goals, and thus adds value
  • Complies with internal writing style and design guidelines
  • Fits into existing content base (e.g. regarding subject and writing style)

Readership-related demands


  • Targetedness (audience addressed)
  • Appropriate approach (e.g. didactic as with tutorials), informative, etc.
  • As easy to consume as the subject permits

A Scrivito-based app lets you support editors already in the content creation phase with meeting some of the textual requirements listed above without using workflows: By adding content validations to widgets or pages, mistakes that can be detected programmatically can be indicated to editors. These mistakes include punctuation or common spelling issues, missing attribute values (e.g. a page description or author name), lengthy paragraphs, empty columns, and the like. Everything that can be ascertained by means of an algorithm can be brought to attention as a notification combined with a severity level, helping authors to stay focused on the important.

Workflows

With Scrivito, workflows are a means to assign website areas, however extensive or small, to teams for editing them and publishing the working copy concerned.

Workflows are included in “Company” and above business plans. Admins and CMS users who have been granted the “Manage workflows” permission via their team membership can find an equally named item in the main menu at the top right. Clicking it, lets them define workflows using the following dialog:

In essence, a workflow is made up of content editing constraints and two team lists, one for editing the content narrowed down by the constraints, and one for publishing the working copy. Additionally, workflows can include a review stage in which the teams with publishing permission can check the content in question or make further edits prior to publishing. We’ll come back to reviewing in a moment.

These mechanisms allow you to create work contexts involving purposefully assembled teams dealing with specific parts of your content. If, for example, your company publishes case studies, you could set up a corresponding team and a workflow:

  • Put all users occupied with writing case studies into a “Case study authors” team. Don’t grant the team any permissions if you want to prevent its members from publishing working copies. They will still be able to edit content.
  • Define a workflow, “Maintain case studies”, where the constraints open nothing more than the case studies section to editing. Select the “Case study authors” team from the “Teams with editing permission” list, and specify the “Teams with publishing permission”, e.g. “Chief editors”.
  • If you want the “Teams with publishing permission” to review case studies, enable “Include a review stage”. This adds editing permission to those teams and prevents the “Case study authors” from making further changes after submitting the working copy for review.

Using workflows

If an editor wants to create a working copy, they are asked to select the workflow to use. The editor will be offered only workflows that permit them to edit content through their “Teams with editing permission” membership. If this applies to exactly one workflow, it is selected automatically. If the editor is no member of any of the editing teams specified in all workflows, the “Default” workflow is selected automatically.

If a working copy’s workflow includes editing constraints, only those CMS objects explicitly permitted by the provided definition can be modified.

Publish requests and reviews

As indicated above, workflows feature an optional review stage. If enabled and used strictly, the members of the “Teams with editing permission” are meant to provide the intended content but cannot publish as they haven’t been granted the “Publish all content” permission through their team memberships. Instead, after finishing their additions or changes, an editor clicks “Publish request” to have the changes in the working copy reviewed.

From then on, the working copy is no longer editable by the “Teams with editing permission”, and members from the “Teams with publishing permission” can now review the content, make further changes to it, and finally publish the working copy. Reviewers can also leave the review or hand the working copy back to the editing teams, should more extensive adjustments be necessary.

Editors may cancel their publish request (in case they’ve overlooked something, for example) as long as the actual reviewing has not yet started. As soon as a user from the “Teams with publishing permission” has committed themselves to reviewing the working copy, the “Publish request” cannot be taken back anymore.

Submitting working copies is mandatory for regular editors since they cannot publish on their own. As mentioned, chief and senior editors (or what you named your teams in your individual setup) are allowed to publish, but they, too, can choose to submit a working copy for review.