Approved publishing workflow
Workflow allows you to set up and configure approval sequences between groups of administrators. This allows an administrator to set up a process such that a specific group of user can edit content but their changes are then passed to another group for inspection and approval prior to publish. Workflow handles both the sequence and levels of access at each configured stage and also handles the email communication to each user group to let them know there are actions waiting for their approval. Sitekit CMS's workflow system has been substantially reworked in 10.3 and workflow has been added to posts in 10.4
Sitekit CMS ships with a default workflow called Approved publishing. This page gives an overview of that workflow and how it can be used. There are also two specific help pages providing context sensitive help:
- Configuring workflow - how to set up schemes, stages and actions.
- Applying work flow to specific assets
- Workflow status - how communication messages are displayed.
The general structure of work flow
Workflow currently only applies to pages and posts. Workflow is configured in actions via the following hierarchical structure:
- Site -Workflow is applied to a site via a scheme. It can be applied on a site wide level via a single universal scheme or alternatively a site can have one or more schemes applied to it.
- Scheme - A scheme is made up of several stages. Schemes can be applied to specific asset classes. Typical scheme names would be 'approved publishing'.
- Stage - A stage is made up of several actions. Stages are given descriptive verb titles like 'editing' and 'publishing'.
- Action - These define what is done eg 'request publish' Their titles are used in the modified work flow button seen on the page editing screen.
- Stage - A stage is made up of several actions. Stages are given descriptive verb titles like 'editing' and 'publishing'.
- Scheme - A scheme is made up of several stages. Schemes can be applied to specific asset classes. Typical scheme names would be 'approved publishing'.
This simple structure is deceptive. With it you can create extremely complex and interrelated n-tier processes between many different groups of administrators.
A default workflow example
This example takes you through the default workflow implementation at each stage on the hierarchy and shows you the end result. The example is intended to step through the simple default edit - approval scheme.
Scheme level
The CMS ships with two pre-built schemes and defaults to the 'instant publishing' one which allows all user to save and publish to the site straightaway. Effectively this turns off work flow. In order to turn it on you should select 'approved publishing' as the scheme to use from the drop down and click apply to site.
User groups / roles
By default, when the approved publishing system is set up all the roles/groups are set to 'anyone'. To get benefit from the system you need to add in the specific groups that are relevant to your own processes and approval hierarchy. In the table below you can see that we've made the local 'publishers' administration group the relevant role for the published stage. Roles and groups occur in two locations in workflow configuration:
- Role / group at stage level - This is the group of people that will be notified when an asset is moved to that stage.
- Role / group at action level - This is the group of people who will be able to see a button for the relevant action on the toolbar when they open the page for editing.
Stage level
The default approved publishing scheme comes with the following pre-configured stages:
As you can see everyone has access to the editing, publishing and deleting stages but only members of the publishers group can perform the publish itself. Drilling down to the relevant actions, you can see the following for the action relating to 'publishing':
Action level
The specific actions are then used to create the buttons at the top of the page edit scheme:
The resulting workflow
The final result is a process as outlined below:
1. Editor A logs into admin - as the general administrator they belong to the 'anyone' group.
2. The editor then creates a page as usual and when satisfied with it they click on 'save' then 'request publish'. NOTE save always needs to be clicked first in workflow, otherwise a 'do you want to discard unsaved changes' popup appears.
3. As seen from the actions table above clicking on 'request publish' changes the stage to the publishing one. The notify and email checkboxes are ticked which means that the administrators in the subsequent group (publishers) will get a new message in their task section under the edit menu, as shown below, and they'll also get an email notifying them of this. This will go to all administrators in the relevant group.
4. The publishing function is only available to administrators in the 'publishers' group. Users in that group will see the following:
5. These publisher administrators have two options based on the publisher actions, Publish and Cancel:
6. If they click Publish, the page is published and the next stage is published. If they click Cancel as can be seen above this triggers a notification and also a mandatory comment. So the publisher is presented with the input box below:
7. After submission of the above form the editor will receive a note in their tasks screen when they next login reminding them to make the additional changes:
Also if they reopen the page the publisher's note is displayed at the top of their editing screen:
In summary, a flow chart for the four default stages is below:
