Reviewing Documents in Accordance with Coding Rules

Project Admins can configure coding rules to ensure that review work applied to each document meets the protocol and standards of the review. This article covers how coding rules work when doing document review. Use this article to understand:

  • When coding rules are active in your project
  • How to review documents in accordance with coding rules

If you're a Project Admin who wants to learn how to create coding rules, see our Use Coding Rules to Structure Review article.

What are coding rules? 

Coding rules are rules that project admins can configure to enforce certain review behaviors. There are two types of coding rules:

  • Conditional rule: Links two pieces of review work together, with one designated as the condition and the other designated as the requirement. When a conditional rule is active, it requires users to apply specific review work (the requirement) when the designated review work condition is met. 
    For example, Project Admins may use a conditional rule to require that users code documents as Review Status: Reviewed if they meet the condition of having applied an issue code to the document. Conditional rules require an action on the part of the user reviewing the document. 
  • Auto-code rule: Automatically codes all documents in a particular context (i.e., exact duplicates, attachment families, email threads, or document versions) when one document in that context is coded.
    For example, a Project Admin can create an auto-code rule to ensure that when one document is coded with a code in the Privilege category, the same code is applied to all exact duplicates in the project. Auto-code rules do not require additional effort from reviewers; the codes are automatically applied to the contextual documents.

Requirements

To review documents in accordance with coding rules, a reviewer must have permission to use/apply to the required codes and review work. 

Review documents in accordance with conditional rules 

When you're reviewing a document, you can see all the conditional within your project to make sure you apply the proper review work. To do so, select the arrow button in the header of the coding panel, then select View conditional rules.

This opens a dialog that lists the Requirement and Condition of each rule.

When you apply review work that meets the condition of a conditional rule without applying the requirement, a notification states Your changes violate conditional rules.

In the above example, the document was rated Hot, but no note was applied. Since the condition is Rated Hot and the requirement is Has Notes, this document is violating the condition rule. 

To comply with the rule, apply the review work listed as the requirement. 

Important

If you close the review window while the document is still in violation of a conditional rule, none of your changes will be saved, including changes that are not in violation of the conditional rule. 

If you attempt to move to another document without satisfying the requirement, a notification warns you Current review state violates conditional rules! Any changes on documents with conditional rule violations will not be saved.

From here you have two options:

  • Select Continue: Move to the next document and lose any changes you have made to the document, including changes that were not in violation of the conditional rule
  • Select Cancel: You remain on the current document, which allows you to apply the required review work.

Note

If Admin Override is turned on for the conditional rule, Project Admins can save changes in violation of conditional rules, including applying a condition without applying the requirement. They will not see the warning that their changes will not be saved. Any documents coded in violation of a conditional rule are displayed on the Conditional rules tab of the Project Settings page, so Project Admins can keep track and do quality checks later.

Review documents with auto-code rules 

Auto-code rules are configured by Project Admins to ensure that when one document within a specified context (e.g. exact duplicates, attachment families, email threads, or document versions) is coded under a particular coding category, all documents in the specified context are automatically coded in the same way. This is useful to reduce the number of documents that need to be manually reviewed, and can make sure review work is automatically applied to meet a review's requirements, such as ensuring that attachment families are coded consistently.

When you're reviewing a document, a wand in the header of the Codes tab indicates that at least one auto-code rule is active in your project. There is no action that a reviewer needs to take for auto-code rules to take effect, and it's fine to code the document as you normally would.  

Optionally, you can select the wand to:

  • See which coding categories your project’s auto-code rules apply to
  • [If you have Auto-code override permission] Ignore the auto-code rules for the current document

When you select the wand, a dialog with your options opens.

If you have the Auto-code override permission, you can apply codes to just  the current document, instead of propagating codes to all the documents in the specified context(s). To do so, select Override for this document. 

override for this document.png

Any documents excluded by this action will be identified as violations on the Project Settings page, so Project Admins can keep track and check on them later.

Note

The Total document count reflects the maximum number of documents that could be affected based on all the auto-code rules in the project. Depending on which codes you actually apply, the number of documents actually affected might be lower.

To see the project’s auto-code rules, select See auto-code rules toward the bottom of the dialog.

This expands the dialog to display all the auto-code rules in the project.

Based on the screenshot above, there is one auto-code rule on the project: when a document is coded within the Responsiveness coding category, that code will be applied to all documents in the email thread.

When you apply a code, the number of documents coded via auto-code is displayed in a notification when you move to the next document. 

Here are some additional details to know about auto-code rules:

  • The auto-code rule does not retroactively apply codes for documents coded prior to the creation of the auto-code rule 
  • If your auto-code rule includes a mutually exclusive coding category, then applying that code to a document overwrites any previously applied code from that category. 
    For example, let’s say that you have a coding category with two mutually exclusive codes: Privilege: Privileged and Privilege: Not Privileged. Prior to setting up the auto-code rule,  one document in the family was coded Privilege: Not Privileged. Then, a Project Admin adds an auto-code rule that applies the Privilege: Privileged code to all families. If you code a parent document as Privilege: Privileged, it will also auto-code all associated children as Privilege: Privileged. Because you are applying an auto-code rule that uses a mutually exclusive code, the previously applied code Privilege: Not Privileged will be removed and overwritten with the Privilege: Privileged code.
  • If you choose to override auto-code rules, they will only be overridden for the document you are currently on; once you close the document or move to a new one, auto-code rules will automatically become active again.  
  • Auto-code rules can only be configured for codes and ratings. They will never apply to binders, notes, metadata, or Storybuilder details
  • For users that are subject to Document Access Management, auto-code rules only apply codes to documents they have access to, which may result in some documents in a given context not having the code applied

Conditional rule violations created by auto-code changes

Sometimes, conditional rules and auto-code rules can be in conflict. If this happens, documents coded via auto-code take priority and will always get coded, regardless of conditional rules that might be violated. For example, a project has:

  • A conditional rule requiring a code in the Privilege category whenever a Responsiveness: Responsive code is applied
  • An auto-code rule for attachment families that applies to the Responsiveness category (but not one for the Privilege category)

If a reviewer codes an email with the Responsiveness: Responsive code and a Privilege: Privileged code, that document is in accordance with the conditional rule: it meets the requirement set by the condition. 

Because of the auto-code rule, the Responsiveness: Responsive code will be auto-applied to all attachments to the email, but they do not have a Privilege code applied (since there is no auto-code rule for that category). That means that the attachments are in violation of the conditional rule.

This is the case whether the document is coded in the review window or from the results table as part of a batch action.

When documents are auto-coded in violation of a conditional rule from the review window, a notification warns you # auto-coded documents are in violation of conditional rule(s). 

Documents coded in violation of conditional rules from a batch action are listed on the batch action card on the homepage under the Batches & Exports column. 

Important

For batch actions, this situation only applies when the contextually related documents were not included in the batch action. If they were selected as part of the batch action, they will not be coded in violation of the conditional rule, because the batch action was attempting to act on them directly rather than through auto-coding.  

The relevant  page for the coding rule on the Project Settings page identifies all the documents that are in violation of coding rules. This makes it straightforward for Project Admins to access and quality check review work on these documents before finalizing review.