How does DocRead differ from Workflow?
DocRead for SharePoint is the only policy management software that integrates straight into SharePoint and allows compliance professionals to distribute and track their policies and procedures.
We often get asked – why do we need DocRead when we can do it in a workflow?
Here’s how DocRead differs from a workflow engine such as the one that ships with SharePoint or a third party one (e.g Nintex or K2).
Workflow is triggered once when the document is checked in and published. DocRead is also triggered when the Document is published, but it also “listens” for membership changes in your groups and audiences. For example, if you required that a “Health and Safety Policy” is read and acknowledged by all new starters, DocRead will automatically send out a required reading task as soon as new starters are put into your groups and / or audiences. This works equally as well for users moving between departments and joining projects or teams (we call this Smart Move).
DocRead works across Web Applications, Site Collections and Sites
All of a users reading tasks are accessible across sites, site collections and web apps. This means that a DocRead web part can be placed onto a MySite and will show the user their entire reading list. To achieve this in workflow would require the provisioning of a users task list on a MySite and the ability to write tasks into it, via a custom activity.
DocRead can send to Audiences
One awesome feature of DocRead is its ability to work with SharePoint audiences scaling to 10’s of thousands of users. Workflow can only target SharePoint groups, therefore lacking much of the power that DocRead offers. For example, if you needed to be specific, by creating specific rules for an audience you can easily target policies to all users working in a certain site / country, who are line managers and have a surname of ‘Smith’ or to all users that belong to a certain department.
DocReads reporting is something to write home about
DocRead is backed by a comprehensive reporting system, that allows DocRead Administrators and Publishers to track the progress of their documents. e.g. you can see for Document X that 40% of your users have acknowledged, 30% are overdue and 30% are still required to read. All of the reports can be exported to a variety of formats including pdf.
Workflow uses workflow history, but this offers no way of slicing and dicing the data across document, audience, user, date due, status, and so on.
DocRead has purpose built web parts
DocRead also ships with a series of web parts, that allows a user to view and acknowledge all of their required reading, across all sites (and web applications) if needed. This makes it ideal to place into a MySite.
DocRead is easy
Once DocRead is installed at the farm level and a set of DocRead administrators have been configured at Site Collection level, it’s so easy to add DocRead to an existing library.
DocRead naturally extends the document metadata properties to target a group
To achieve the same result with workflow an initiation form would have to be generated which would be more confusing for end users and would leave room for error. In addition to this, it would not be possible to target an Audience (see above).
DocRead generates Reading Receipts
DocRead automatically generates and stores Positive and Negative Reading Receipts. These can be crucial in litigation purposes!
A Positive Reading Receipt is issued to certify that a person has read a document. DocRead automatically generates Positive Reading Receipts only when a person explicitly confirms reading a document via the DocRead Confirmation Dialog.
A Negative Reading Receipt is issued to register the fact that a person has never read a document. This could be because the document has been deleted before they had the chance to read it or because they moved from one audience to another (i.e. moved department) and they never read documents assigned to the audience they are leaving. Negative receipts always clearly state the reason that caused the Receipt to be generated.
For an more details explanation on Reading Receipts have a look at this knowledge base article.
A Reading List can be seen from many places
On top of this, we also show a ‘red’, or ‘amber’ status message when the user visits the library, clearly signifying whether they have overdue, or assigned required reading tasks on any document in the library.
DocRead has been built with scalability in mind
As some organizations have a huge number of employees, we have spent a lot of time ensuring that the processing of “who needs to read what”, is all done as efficiently as possible, usually out of hours as a SharePoint Timer Job.
Document and web life-cycles
We have also considered some really tedious User Case scenarios in DocRead which literally took us weeks to cater for. (Imagine doing any of these with a custom workflow attached to a library!)
- Move a document to another library
- Delete a document / library / Web / Site Collection / Web App
- Rename a document / library / Web / Site Collection / Web App
- Copy a document
- Delete a group / audience
DocRead can benefit from Workflow!
Having said all the above, it may also surprise you to know that DocRead can actually benefit greatly from Workflow. For example, by using workflow with DocRead you can easily do this :
- Joe Brown – Creates a SOX Policy and checks it into the Doc Library.
- Approval Workflow begins which routes to Fred Smith.
- Fred Smith looks at the policy then approves.
- The Policy gets published.
- DocRead the distributes the policies to the required groups or audiences and allows X days to read and acknowledge it.
It can also get much more complex if needed.
Hope this helps you understand why DocRead isn’t workflow.
To read more about DocRead check out the product site