Expected US Release: June 28, 2019
Expected International Release: July 5, 2019
In this release, you can now auto-code contexts! This allows project administrators to drive consistency in review and streamline the review process, while giving reviewers increased confidence in the quality of their coding work. Additionally, we’ve improved object permissions behavior and added the “Has Notes” search term to assignment review criteria.
Auto-code rules can be created by project admins to ensure that all documents in a given context (i.e., exact duplicates, attachment families, email threads, versions) are coded similarly. For example, admins might want to ensure that all documents in an attachment family are given the same code under the Responsiveness category. Instead of relying on people to manually apply the same Responsiveness codes to each document in the attachment family, the project admin can configure an auto-code rule which specifies that anytime a document is coded under the Responsiveness category, the same code is automatically applied to all members of the document’s attachment family.
Reviewers can view auto-code rules in the batch coding panel of the results table and in the review window. Auto-code rules are represented by a wand icon, as well as a blue sparkle icon in the context panel for applicable contexts. Clicking on the wand will open a dialog that shows the project’s auto-code rules, as well as the number of documents associated with each context.
With the addition of this feature, we have also added a new Auto-Code Override permission to the project settings page. If a group has this permission, users in that group will be able to prevent auto-code rules from automatically applying codes to contextual documents. Only project admins will be automatically granted this permission with this release. However, new groups created using the “Case leads” group template will receive the Auto-Code Override permission going forward.
Improvement to object-level permissions
This feature introduces improvements to how administrators manage permissions on objects for individual users and for groups. With this release, permissions can be viewed and revoked at an object level by user and by group in Project Settings.
You can read more about group permissions in this article.
Additionally, if you revoke a group’s ability to receive an object type, and they’ve already been shared an object of that type, you can now select to maintain permissions on those objects for the group. You can always revoke the group’s object permissions in the Groups tab, as described earlier.
Addition of Has Notes to assignment review criteria
Upon creating an assignment group, you can now include Has Notes as a component of assignment review criteria. For example, you might want the documents to have a code and a note to be considered “reviewed.” This example is shown in the screenshot below.
You can learn more about review criteria by visiting this article.
Ability to revoke self-assign permissions
Now, admins on assignments can revoke self-assign permissions previously granted to another user. This gives admins more fine-grained control during assignment administration.
For more information on self-assigning, visit this help article on assignments.