SharePoint Workflow allows a set of activities to process in either sequential or parallel, more often than not, one or more of those activities involves human intervention such as ‘approve a document’, or ‘complete a task’ and so on. This in itself goes a long way to ensure regulatory compliance because the right information is shared with the right person at the right time and a step in a defined process cannot be leap-frogged or missed completely.

Once one step is completed, the ‘next in line’ is notified and so on until the task is completed. A Workflow can be used to gain approval, collect feedback or track specific items. Law suit defences can be built showing Workflow as proof that the relevant approvals were given and digital signatures obtained. Administrators can view the progress and status of current Workflow’s and how long they have been assigned.

Isn’t DocRead Workflow ?

To the true definition of the word ‘Workflow’ – DocRead is in fact a set of Workflow processes that allows a publisher to send out a policy to be read by a group of users. Each user then receives a ‘reading task’ and email to read and acknowledge that policy by a specific date. However, DocRead hasn’t been built  using SharePoint Workflow for a variety of reasons such as performance, security, limitations and lack of reporting. However, DocRead can easily be used in conjunction with Workflow, for example, you may wish to get approval for your policies before distributing them.

To find out more about how DocRead differs from Workflow, please read this blog post : How does DocRead differ from Workflow?