An in-depth look at DocRead Reading Tasks

What is a Reading Task ?

A DocRead ‘Reading Task’ can be defined as something that an end-user must carry out when they are required (or recommended) to read a document by a specified deadline. If a publisher assigns a document to a group of users with 150 users, then this will create 150 Reading Tasks. All Reading Tasks are stored in a DocRead SQL database that is configured automatically by the Farm Administrator at installation time.

Having a separate DocRead database gives us many benefits over storing them in SharePoint. To read more about these benefits and also about the general architecture behind DocRead, please read DocRead Architecture Design.

It is worth discussing one of the major benefits that a separate database gives you here. As all Reading Tasks are stored in one database this means we can show an end-user all of their required reading across the entire farm. So if DocRead publishers assign documents stored in the Intranet, Collaboration site and maybe a project portal, then an end-user will see them all in one web part. This is really convenient for users because they don’t have search through endless sites looking for document they are required to read.

If you have ever tried to achieve something similar using SharePoint you will know that it’s not possible to view documents, tasks or in fact anything across site collections, let alone web applications.

How does an End-User see a Reading Task ?

So now you know what a Reading Task is, how does an end-user (who is required to read a document by a deadline) interact and see a Reading Task ? Reading tasks can be accessed in several ways, but the most popular is to place a DocRead web part onto a busy page such as the Intranet Home Page. Placing it on a busy page ensures that users are immediately notified when they are required to read something, which provides a refreshing alternative to a full email inbox! An snippet of what the web part looks like is show below.

docread-web-part

When a user clicks on any of the tasks in the list (above), they are presented with a pop-up window that allows them to read more information about the task and document. It also – more importantly – allows the user to agree to your terms and confirm they have read it. As below :

reading-task-details

DocRead Administrators can also view all of the Reading Tasks (for all users) in the site via DocRead Reporting and also via Site Reading Tasks. In addition to this there is another web part that can be used to show all tasks in that site.

site-reading-tasks

How do you create DocRead Reading Tasks ?

To instruct DocRead to create Reading Tasks an DocRead Publisher needs to assign one or more groups or audiences to a document via the edit properties screen, as in the image below. When the document becomes published (and approved if turned on), this indicates to DocRead that the document is “ready to process”.

DocRead creates Reading Tasks via two methods as discussed below, but it’s worth noting that Reading Tasks are not created immediately after the document becomes published. They are only created during a scheduled job, or when manually triggered by a DocRead Administrator.

Group and SharePoint Audience Management in DocRead

Depending upon your license and version of SharePoint, DocRead allows you to send a document to either a SharePoint Group or a SharePoint Audience. Before proceeding please ensure you understand what the difference is between a SharePoint Audience and a group is.

When you assign a group or SharePoint Audience to a document, DocRead will cache information about that group / audience (and the people within it), inside its own database. As mentioned previously, this is done via a scheduled job and is done for many reasons with the main one relating to performance.

How are Reading Tasks processed?

Reading Tasks are created, amended and deleted in 2 ways as follows.

Automatically via DocRead Timer jobs

After a publisher has assigned a document to a group or audience 3 DocRead scheduled jobs take care of created, updating and deleting tasks :

  1. Reading Tasks Job Schedule’. This timer job is responsible for managing tasks. If a new document is created and assigned, then this job will create a task for each member in the audience or group. This job will also delete tasks (for reasons such as when a user leaves the group) and will create positive and negative receipts.
  2. Audiences Synchronisation Job Schedule’. This job monitors the groups or audiences that have been assigned to documents with DocRead. When changes are detected, the job synchronises the DocRead database with what’s in SharePoint. For very large audiences this job can take a minute or two to run.
  3. SharePoint Objects Synchronisation Schedule‘. This job looks for items in SharePoint that have been deleted, such as Web Applications, Site Collections, Sites and Document libraries. If it discovers anything that is deleted (that previously contained Reading Tasks), it will delete those tasks and create negative receipts for traceability and auditing.

The frequency of each timer job can be amended to suit your needs via an administration screen in Central Admin.

timer-jobs

Manually Triggered by a DocRead Administrator

A DocRead Administrator can also request that Reading Tasks are processed. This has exactly the same effect as the timer job with a few notable differences.

  1. When tasks are manually processed, only the documents within that site will be processed. However, the DocRead timer jobs will process all DocRead-configured documents across the entire farm.
  2. When tasks are manually processed, no changes in SharePoint Audiences will be detected. This means that if you assign a document to a new SharePoint Audience (that’s not been utilised before in DocRead), then we will not assign Reading Tasks. This means only the scheduled job can check for changes to SharePoint Audiences.

Why don’t we process Reading Tasks for audiences manually?

This is done purely for performance reasons. SharePoint Audiences can contain hundreds of thousands of people. The SharePoint API calls to return profile and audience information, and then to cache it within the DocRead database are fairly intensive and can take a few minutes. If we were to allow DocRead administrators to trigger this process manually then it could impact the performance of the SharePoint site serving web pages. SharePoint groups, on the other hand, enjoy much faster SharePoint API calls and are also limited to 4000 members. It’s also very unlikely that organizations maintain large groups in this anyway. For this reason, we allow groups to be processed at the request of the DocRead Administrator.

Conclusion

I am sure you will agree that on the surface DocRead looks like a very simple application that could be potentially created with workflow. However, when you take into account benefits such as those listed below, I am sure you will start to understand how comprehensive and robust the solution is.

Key Benefits

  • DocRead scales to thousands of users and thousands of documents
  • Built in Reporting and Tracking
  • Custom E-mails available if required.
  • Smart Move which will automatically assign ‘Reading Tasks’ to new users as they enter the group or audience. Great for on-boarding, staff on secondment or users joining or leaving projects.
  • Ability to have a unified view of Reading Tasks across the entire Farm.

Want to know more?

Why not take a look at the features in more detail in our DocRead Tour.