This technical article was first published over 2 years ago and may discuss features and approaches that are no longer relevant for the current version of the platform.
This in a first of a series of posts about how to build a custom EPiServer workflow. There is a fair amount of information about EPiServer workflows (most of which are nicely summarised by Frederik Vig in his amazingly useful EPiServer Developer Resources). Hopeful these posts will be able to add to that and also provide further context. Comments are most welcome!
Over the course of five posts I’ll cover the following:
- Part One – Overview and Requirements
- Part Two – Windows Workflow Foundation in EPiServer
- Part Three – Designing the Workflow
- Part Four – EPiServer tasks and working with the user interface
- Part Five – Access control and finishing touches
The out-of-the box workflows in EPiServer cover off some common editor based scenarios such as approval and feedback. However the real world always throws up more exacting requirements that can’t be satisfied by the pre-defined workflows (or any combination of them – remember that you can chain them together).
In these situations you’ll have to build your own custom workflow piece utilising Windows Workflow Foundation and EPiServer’s own library of workflow elements and UI integration.
First up we must start with requirements gathering. This is often a difficult process with workflows as you have to map and consolidate real business processes into a sensible technical solution.
Workflow requirements are always best distilled by a Visio flow diagram. Fact! So here’s ours (click to enlarge).
Looking at the required process, you can see that it’s a 2-stage approval process, where a page is created, sent for approval, and then finally sent through a further approval step, where upon the page is approved one final time before being published.
There are three user roles who interact with this process:
- Creators, who initially create the content and kick off the workflow.
- Approvers, who can decide to approve or decline the content, or pass on the approval decision.
- Publishers, who can approve or decline the content, and publish the content.
This is only slightly different than the out-of-the-box Sequential Approval workflow, but the following differences necessitate a custom solution:
- There are two stages of approval
- Approvers can opt to ‘pass-the-buck’ and pass the approval stage to a fellow Approver.
- The workflow creator is informed at every decision point.
There are some additional requirements that can’t be shown on the diagram:
- Pages can only be published using the workflow
- Only one instance of the workflow can be in progress for a page at any one time.
Over the course of the next four posts I’ll piece together a workflow that meets the above requirements, covering the (very) basics of Windows Workflow Foundation and how you can use them and the integration methods that the EPiServer API exposes to allow any custom workflow to be implemented against EPiServer managed content.