Approval workflows #

This page is for managers who need a second pair of eyes on what is published: HR policies, management announcements, prices on a partner portal. Exponential offers two built-in ways to do it, and a simple third one. The page explains what each feels like for the people involved and links to the step-by-step guides.

Contents #

1. Three ways to approve
2. Approval before publishing
3. Review stages with object states
4. A staging section
5. Choosing
6. What must be running
7. Proof of who approved what
8. Checklist
9. Related pages

Three ways to approve #

Approval before publishing #

A workflow is a list of steps; a trigger connects it to an operation. "Before publishing content, run the approval workflow" is the classic case (Workflows, In short).

What the people see:

1. An editor publishes an article. It is not published; the version waits for approval ("pending").
2. An approver opens My account > Collaboration, looks at the preview and presses Approve, or Deny with a comment for the author.
3. On the next run of the workflow cronjob the approved article is published. A denied version becomes a draft for the author again.

What the Approve event can narrow down (Workflows, 3.2):

An approver never needs their own content approved. Approvers are told by mail about items that wait for them when they tick the collaboration setting Approval on their notification page (Notifications: the user's guide, Collaboration notification).

Setup > Workflow processes (/workflow/processlist) lists every process that waits, in words, with a status bar that says whether the workflow cronjob is scheduled and when it runs next. Cancel... stops a process after a confirmation; no content is deleted (Workflows, 7).

A sample approval setup can be created and removed again with ./console exp:collaborationsampledata --apply, which helps when training approvers (Workflows, 3.6).

Review stages with object states #

Object states are labels every object carries, one per state group. Roles make them matter. The guide's worked example creates a group review with Draft, In review and Approved, and:

• lets visitors (or staff) read only content in the state Approved;
• lets authors edit their own drafts and send them to In review, nothing else;
• lets reviewers send texts back to Draft or approve them.

Set the existing public content to Approved first, or it disappears from readers when the group is created (Object states, 9).

A staging section #

The simplest way: a section Staging that readers' roles do not include. Editors create pages in their final place and assign them to Staging; when ready, the top item is assigned to the reading section and everything below becomes readable at once (Sections, 13.3). There is no recorded approval step, so it suits launches more than day-to-day governance.

Choosing #

What must be running #

• The workflow cronjob (workflow.php, in the frequent part by default). Without it, approved content is never published (Workflows, 6).
• Mail, so approvers learn that something waits.
• Approvers who are reachable. When an approver leaves, clean up as described in Workflows, 10.2.

Proof of who approved what #

The audit trail records content changes, including sections and states, in a tamper-evident log (The audit trail). Combined with the versions page of each object (Versions of an object), the organization can show who changed a text and when.

Checklist #

• To do: Decided which areas need approval and which way fits.
• To do: Approver groups named, with a deputy for holidays.
• To do: Workflow cronjob scheduled and visible in the status bar.
• To do: Approvers have ticked the Approval collaboration setting.
• To do: One test article approved and one denied before going live.
• To do: A procedure for when an approver leaves.

Related pages #

• Workflows
• Object states
• Drafts and pending versions
• Registration and account approval
• Preview before you publish
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.