{"id":94,"date":"2020-12-18T04:17:08","date_gmt":"2020-12-18T04:17:08","guid":{"rendered":"http:\/\/collaboriscom.wpengine.com\/?p=94"},"modified":"2024-01-30T17:56:53","modified_gmt":"2024-01-30T17:56:53","slug":"docread-reading-tasks","status":"publish","type":"post","link":"https:\/\/www.collaboris.com\/docread-reading-tasks\/","title":{"rendered":"Automated content targeting in SharePoint with DocRead Reading tasks"},"content":{"rendered":"

Automated content targeting in SharePoint with DocRead Reading Tasks<\/h1>\n

Note:  <\/strong>This content applies to the on-premise version of DocRead only<\/strong>. For the Office 365 version have a look here.<\/a> <\/p>\n

What is a Reading Task?<\/h2>\n

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.<\/p>\n

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<\/a>.<\/em><\/p>\n

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.<\/p>\n

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.<\/p>\n

__CONFIG_colors_palette__{“active_palette”:0,”config”:{“colors”:{“16871”:{“name”:”Accent Darker”,”parent”:”43816″,”lock”:{“saturation”:0}},”43816″:{“name”:”Main Accent”,”parent”:-1},”4592d”:{“name”:”Accent Lighter”,”parent”:”43816″,”lock”:{“lightness”:1,”saturation”:1}}},”gradients”:[]},”palettes”:[{“name”:”Default”,”value”:{“colors”:{“16871”:{“val”:”rgb(3, 3, 3)”,”hsl_parent_dependency”:{“h”:80,”l”:0.01,”s”:-0.05}},”43816″:{“val”:”rgb(171, 212, 107)”,”hsl”:{“h”:83,”s”:0.5497,”l”:0.6255,”a”:1}},”4592d”:{“val”:”rgb(244, 250, 235)”,”hsl_parent_dependency”:{“h”:84,”l”:0.95,”s”:0.58}}},”gradients”:[]},”original”:{“colors”:{“16871”:{“val”:”rgb(29, 23, 12)”,”hsl_parent_dependency”:{“h”:38,”s”:0.41,”l”:0.08,”a”:1}},”43816″:{“val”:”rgb(255, 204, 102)”,”hsl”:{“h”:40,”s”:1,”l”:0.7,”a”:1}},”4592d”:{“val”:”rgb(250, 246, 236)”,”hsl_parent_dependency”:{“h”:42,”s”:0.58,”l”:0.95,”a”:1}}},”gradients”:[]}}]}__CONFIG_colors_palette__ <\/p>\n

Tired of reminding staff to read your company policies?<\/strong><\/span><\/h3>\n

DocRead makes compliance simple<\/p>\n

See how<\/span><\/span> <\/a> <\/p>\n

How does an End-User see a Reading Task?<\/h2>\n

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.<\/p>\n

\"\"<\/span><\/p>\n

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.<\/p>\n

\"\"<\/span>__CONFIG_colors_palette__{“active_palette”:0,”config”:{“colors”:{“16871”:{“name”:”Accent Darker”,”parent”:”43816″,”lock”:{“saturation”:0}},”43816″:{“name”:”Main Accent”,”parent”:-1},”4592d”:{“name”:”Accent Lighter”,”parent”:”43816″,”lock”:{“lightness”:1,”saturation”:1}}},”gradients”:[]},”palettes”:[{“name”:”Default”,”value”:{“colors”:{“16871”:{“val”:”rgb(3, 3, 3)”,”hsl_parent_dependency”:{“h”:80,”l”:0.01,”s”:-0.05}},”43816″:{“val”:”rgb(171, 212, 107)”,”hsl”:{“h”:83,”s”:0.5497,”l”:0.6255,”a”:1}},”4592d”:{“val”:”rgb(244, 250, 235)”,”hsl_parent_dependency”:{“h”:84,”l”:0.95,”s”:0.58}}},”gradients”:[]},”original”:{“colors”:{“16871”:{“val”:”rgb(29, 23, 12)”,”hsl_parent_dependency”:{“h”:38,”s”:0.41,”l”:0.08,”a”:1}},”43816″:{“val”:”rgb(255, 204, 102)”,”hsl”:{“h”:40,”s”:1,”l”:0.7,”a”:1}},”4592d”:{“val”:”rgb(250, 246, 236)”,”hsl_parent_dependency”:{“h”:42,”s”:0.58,”l”:0.95,”a”:1}}},”gradients”:[]}}]}__CONFIG_colors_palette__ <\/p>\n

How do you know if your policies are fully understood?<\/strong><\/span><\/h3>\n

DocRead makes compliance simple<\/p>\n

See how<\/span><\/span> <\/a> <\/p>\n

DocRead Administrators can also view all<\/u><\/strong> of the Reading Tasks (for all users) in the site. They can find the details via DocRead Reporting<\/a> 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.<\/p>\n

\"\"<\/span><\/p>\n

How do you create DocRead Reading Tasks?<\/h2>\n

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”.<\/p>\n

\"\"<\/span><\/p>\n

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.<\/p>\n

Group and SharePoint Audience Management in DocRead<\/h2>\n

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<\/a> is<\/em>.<\/p>\n

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.<\/p>\n

How are Reading Tasks processed?<\/h2>\n

Reading Tasks are created, amended and deleted in 2 ways as follows.<\/p>\n

Automatically via DocRead Timer jobs<\/h3>\n

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

    \n
  1. \u2018Reading Tasks Job Schedule<\/strong>\u2019. 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<\/a>.<\/li>\n
  2. \u2018Audiences Synchronisation Job Schedule<\/strong>\u2019. 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\u2019s in SharePoint. For very large audiences this job can take a minute or two to run.<\/li>\n
  3. \u2018SharePoint Objects Synchronisation Schedule<\/strong>‘. 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.<\/li>\n<\/ol>\n

    The frequency of each timer job can be amended to suit your needs via an administration screen in Central Admin.<\/p>\n

    \"\"<\/span><\/p>\n

    Manually Triggered by a DocRead Administrator<\/h3>\n

    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.<\/p>\n

      \n
    1. When tasks are manually processed, only the documents <\/strong><\/u>within that site<\/strong> will be processed. However, the DocRead timer jobs will process all DocRead-configured documents across the entire farm.<\/li>\n
    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\u2019s 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.<\/li>\n<\/ol>\n

      __CONFIG_colors_palette__{“active_palette”:0,”config”:{“colors”:{“4882e”:{“name”:”Main Accent”,”parent”:-1},”aac4b”:{“name”:”Accent Transparent”,”parent”:”4882e”}},”gradients”:[]},”palettes”:[{“name”:”Default”,”value”:{“colors”:{“4882e”:{“val”:”rgb(52, 52, 52)”,”hsl”:{“h”:0,”s”:0.01,”l”:0.2039,”a”:1}},”aac4b”:{“val”:”rgba(52, 50, 50, 0.4)”,”hsl_parent_dependency”:{“h”:0,”l”:0.2,”s”:0}}},”gradients”:[]},”original”:{“colors”:{“4882e”:{“val”:”rgb(32, 205, 166)”,”hsl”:{“h”:166,”s”:0.72,”l”:0.46,”a”:1}},”aac4b”:{“val”:”rgba(32, 205, 166, 0.4)”,”hsl_parent_dependency”:{“h”:166,”s”:0.72,”l”:0.46,”a”:0.4}}},”gradients”:[]}}]}__CONFIG_colors_palette__ <\/p>\n

      See what DocRead can do for you<\/strong><\/h3>\n

      Book a custom demo with one of our experts now to discuss your specific requirements and find out how DocRead can help you stay compliant<\/p>\n

      book now<\/strong><\/span><\/span> <\/a> <\/p>\n

      Why don’t we process Reading Tasks for audiences manually?<\/h2>\n

      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\u2019s 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.<\/p>\n

      Conclusion<\/h2>\n

      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.<\/p>\n

      Key Benefits<\/h3>\n