Batch 2nd Review

[emilyvforrest]

Hi guys,

 

Wondered if there was a way around completed batches defaulting to 'Read Only' mode.

 

We have an issue when the client wishes to review a batch for the second time as they are unable to revisit the initial batch as it becomes locked from editing. 

[ŁukaszBachman]

Hi Emily,

 

It's true that batches are locked from editing once completed, but you still have some options to change the coding. Those depends on how many items are required to be updated.

 

If it's just a handful of items from the batch, then I suggest you simply open those items in Previewer and modify tags manually. Since each coding field is mapped to a tag, then changing a tag will essentially change which option from a coding field is applied. It's very easy to alter any mistakes that way.

 

On the other hand if entire batch requires review, then you can do the following:

1. Search for items in that batch using "Query for items" button (results will show in main search UI).
2. Remove all tags that are a part of the coding layout from those items.
3. Select all items and choose "Create batches" from right-click menu.
4. Select the same coding layout as originally used and create the batch.
5. You will now have a batch with status "New" and you can review it from scratch.

Essential step here is step 2, as without clearing the tags previously applied our batch creation mechanism would set the status to 100% complete right after batch is created. I hope that helps.

[emilyvforrest]

Thank you but I don't think I explained fully.

 

If a batch has been reviewed and tagged and is now considered complete, if someone else is tasked with checking the tags applied in that batch as part of the second tier review (with the view to amending the tags, removing them or approving them), they can't go through the batch again as its locked as 'Read Only'.

 

Is there a simple way around this?

[AdamS]

Perhaps a new power/privilege could be created to allow a completed batch to be reviewed and changes made while still using the review tabs?

 

I can see where the review would be handy without the need to have to either remove all existing tags and redo, or open the document in the preview tab before making changes.

[jon.pearse]

I have discussed this with the dev team and they are looking at options where batches can be reopened for QA purposes.

 

One option is to add another state called "Reopened" which would allow a user (the person doing the check) to change coding to batches once they are completed. Then privileged users could mark it as "Completed" again once done. We are also looking at adding the ability to capture the exact trail of coding decisions. This would be useful for audit purposes.

[AdamS]

Jon that would be great. I know from experience that investigations are often fluid and what is relevant at the beginning may change as things progress. Having the ability to 'reopen' previously completed batches will allow an easy way to QA and make changes as needed. Just one comment though, we would need this ability to be persistent, by that I mean be able to reopen a batch as many times as is needed.

[JakeR]

Hi Everyone, 

I was just wondering whether or not this feature has been implemented yet, I can see this chain of comms was from Feb 2017 so i'm guessing it has but I struggling to find it. I have a similar Issue to emilyvforrest where a client has reviewed a batch and would consequently like to amend some of the tags applied to the documents. However, due to this batch being already completed it has now changed to Read-only. From the above, I understand there are ways around this such as the query for Items but it would be more beneficial for the batch to be reopened as previously discussed. This makes it easier for the client to review the data on Intella. 

Thank you in advance for your time.

[jasoncovey]

This is a particularly significant and ongoing issue for my users, as well.  Although the simplified Review UI has been universally well-received by reviewers, and is now our default approach for even single-user document reviews, a lack of flexibility has created several challenges. 

It's difficult for a reviewer to understand why they can't return to a document batch they previously reviewed and make tagging changes based on new information that has come to light, which is totally normal given the constantly-moving goalpost in litigation and ediscovery (as well as the other contexts mentioned previously).  In fact, it's not uncommon for certain documents to be subject to multiple coding changes as new facts and information becomes available during the course of discovery.

I have recently provided Jon with some extremely detailed explanations with respect to these issues, which I hope will be helpful in making Connect more flexible for these types of workflows.           

[ŁukaszBachman]

Hi guys,

As an author of Batching & Coding functionality, I can say - I hear you I will put this on a short-term wishlist, but "short" will probably mean at least a couple of releases.

[ŁukaszBachman]

Just a quick update - we are starting development of few extensions in this area. These are:

1. New permission: users with special permission will be able to reopen their own batches and later close (mark as Completed) them manually.
2. New permission: users with special permission will be able to reopen batches assigned to any user and later close (mark as Completed) them manually.
3. New permission: users with special permission will be able to mark batch as Completed regardless of previous status (with an exception of Archived status)
4. New permission: users with special permission will be restricted to seeing only batches assigned to them, therefore working in isolated mode where they case manager can only assign them batches. They will also not be able to grab unassigned batches by themselves.
5. Modification: users with "CAN_CHANGE_BATCH_ASSIGNEE" permission will be able to reassign batch regardless of the status (allowing for completed batches to be reassigned) 
6. Modification: batch creation dialog will be extended with an option allowing to skip initial calculation of batch progress upon its creation. This will allow for new batches to be created for the same set of items using the same coding layout as previously, without automatically marking the newly created batch as Completed. 

Note: status of batches in "Reopened" state will not be automatically recalculated. Therefore if you reopen a batch then the only way to complete it will be to click on "Complete" button.

If you have further suggestions I'm all ears. Thanks for feedback!

[jasoncovey]

So I read this several times today to make sure I understand everything that being described, and I think all sounds fantastic.  This solves the majority of the problems that have been described in this thread.  

One additional issue that came to mind when discussing internally and thinking about scenarios we have grappled with previously.  In culling data and creating batched review sets, it's fairly common to run into a situation where, as a results of the entire content of a ZIP archive being include, or due to false positive search hits, that a large portion, or even the entirety of a batch can be determined as being non-responsive without a full, document by document review.  

In these situations, we are frequently asked if there is a way to bulk-code the documents as non-responsive and make the batch as complete.  This presents a problem because, although we train users to query for items into the main previewer where the bulk tag can then be applied,  the limitation is that this action is not recorded back in the Review UI because:  (1) check marks are not added to the now-coded documents; and (2) the batch is not marked complete as a result. 

What this results in looks like the following screenshots.  First, in the All Batches view, despite the appearance of the progress, every single document has, in fact, been tagged (and I know there is difference between tagged and coded) with either the responsive or non-responsive tag, from the same coding palette.  Of course, end users can't begin to understand how "completed" work could look like this, and ask all kinds of questions that we can't really answer other than to say, ignore what you are seeing, everything is actually fine despite what you see.  That doesn't go over well with lawyers!  By the same token, people LOVE the progress and status data, it's the only such data Connect provides us, so it would obviously be ideal if it could be as accurately as possible and avoid ever being misleading. 

 

In the next screenshot, which was taken inside of the Wave 03 Email-7 batch, you can see what we are talking about.  As it turns out, all of the spreadsheets are non-responsive, and there are literally hundreds of them, which exist across over two dozen batches.  Since they can be identified as non-responsive at a glance, without reviewing at all, we can't spend the time coding each one individually.  Therefore, we have to query for items and bulk tag in the main previewer for sake of efficiency.  Unfortunately, we have found this to be a very common scenario across dozens of litigation matters, and have to have a way to address it.    

With all that explained, regarding No. 3 in your list, are you using the term "Closed" to mean the batch will be marked as" Completed" via the green button?    In other words, this could be used by someone assigned this permission to address item batches that are not technically "completed" under the current definition?  Another question is, when you are saying Closed, will the percentage also move to 100, or will it stay where it is, but just display the green Completed button?  I know that our preference would definitely be for 100% due to the issues already described.      

On the subject of batching, generally, the only other thing we're in desperate need of is the ability to batch documents in sort orders OTHER THAN Family Date.  This is particularly the case with incoming load file productions, which may or may not contain adequate metadata for Intella to calculate perfect family dates,  or when such a production is not IN any particular date order, which definitely happens all the time.  This puts us in a position of not being able to batch the document in bates numbered order, which then breaks up document families and creates an extremely difficult situation for us to resolve.

Hopefully that was instructive, and I'm looking forward to seeing these features make it into a future version of Connect!

 

Jason  

[ŁukaszBachman]

Hi Jason,

I made a mistake and used term "Closed" when I meant "Completed". I will update my previous post.

We are also looking into supporting other sort orders, I haven't mentioned it here because it is not relevant for the original thread. If all goes well we should add this feature in next release.

As for the progress recalculation - do you think a button "Recalculate progress" could work here? 

[jasoncovey]

I think that would work!  As long as we would still be able to accommodate the scenario you described in Item No. 6 in your list, that sound like it would be a very simple solution.

Jason

[ŁukaszBachman]

Hi guys,

Just wanted to give you a quick update on this. The development of all of features mentioned above has been completed. I'm now in the process of testing and QA these changes. They will become a part of the next (2.2.2) release.

[AdamS]

Nice one, thanks for the update

[ŁukaszBachman]

The release is out: