How does DocRead differ from Workflow?
DocRead for SharePoint is policy management software that integrates straight into SharePoint. It allows compliance professionals, HR professionals and business users to easily distribute and track policies and procedures.
We often get asked - why do we need DocRead when we can use 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).
Trigger Points
Workflow is triggered once when the document is checked in and published. DocRead is also triggered when the Document is published. However, it also "listens" for membership changes in your groups and audiences.
As an example, let's assume new employees need to read and acknowledge a "Health and Safety Policy". DocRead will automatically issue a required reading task as soon as new starters are added to groups and / or audiences. This works equally 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. Meaning a DocRead web part can be placed onto a MySite and will show the user their entire reading list.
This would be much harder to achieve with workflow. 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.
DocRead reporting is something to write home about
DocRead is backed by a comprehensive reporting system. The reports allow DocRead Administrators and Publishers to track the progress of their documents.
For example, 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. These allow 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
The target audience or group needs to be selected in the Required or Recommended audience by a DocRead Publisher. They also need to specify the number of days allowed to complete the task.
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
We have also integrated DocRead into Document Libraries so a user required to read a document can easily see the reading on that library. Each document also has a 'Reading Requirements' menu option.
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!)
1) Move a document to another library
2) Delete a document / library / Web / Site Collection / Web App
3) Rename a document / library / Web / Site Collection / Web App
4) Copy a document
5) 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 :
1) Joe Brown - Creates a SOX Policy and checks it into the Doc Library.
2) Approval Workflow begins which routes to Fred Smith.
3) Fred Smith looks at the policy then approves.
4) The Policy gets published.
5) DocRead the distributes the policies to the required groups or audiences and allows X days to read and acknowledge it.
This is a fairly simple example, however it's possible to combine the products to cope with far more complex requirements.
Hope this helps you understand why DocRead isn't workflow.
To read more about DocRead check out the product site