What is a Reading Task?

A DocRead 'Reading Task' is something an end-user must complete 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 configured automatically by the Farm Administrator during installation.

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. By storing all Reading Tasks in one database this means an end-user can see 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 documents 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 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 interact and see a Reading Task ? Reading tasks can be accessed in several ways. However, 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. This provides a refreshing alternative to a full email inbox! An snippet of what the web part looks like is show below.

A user must click on a task in the list (above) to find more information about the item. After clicking, a pop-up window is presented, an example is pictured below. More importantly, this window allows the user to agree to your terms and confirm they have read it.

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

How do you create DocRead Reading Tasks?

A 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), this indicates to DocRead that the document is "ready to process".

DocRead creates Reading Tasks via two methods, as discussed below. However, 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 DocRead license and version of SharePoint, you can send documents 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 audience to a document, DocRead will cache information about the people within it. This information is stored within its own database. As mentioned previously, this is done via a scheduled job and is done for many reasons, the main one being to increase 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.

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 used before in DocRead), then DocRead 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?

Above all, 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 automatically assigns 'Reading Tasks' to new users as they enter the group or audience. Consequently, it's 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.