Do Hyperlinked Documents Need to be Produced?

In this week’s Case of the Week, Kelly Twigger breaks down the crucial decision in Nichols v. Noom Inc., 2021 WL 948646 (S.D.N.Y. 2021), a case with far-reaching implications for how legal teams manage the collection and production of hyperlinked documents. This episode focuses on a pivotal challenge in modern eDiscovery: the complications of dealing with hyperlinks in emails instead of traditional attachments—and the technological limitations of collection and review platforms in handling this new reality.

Kelly explores the Southern District of New York’s analysis, led by Judge Katherine Parker, which emphasizes the evolving nature of electronically stored information (ESI). The case examines whether hyperlinked documents should be treated as attachments and the proportionality concerns of forcing defendants to recollect data using forensic tools like FEC from Metaspike.

The practical implications are significant: Noom’s use of Google Vault for data collection raised issues about missing metadata, document relationships, and the plaintiffs' inability to link hyperlinked documents back to emails. Kelly provides valuable insights into how parties must adapt their ESI protocols to account for platforms like Google Apps and Microsoft Teams, where hyperlinked documents are prevalent.

With key takeaways on the necessity of planning collection strategies that address hyperlinked content, Kelly also discusses the court’s reasoning in balancing discovery obligations with proportionality concerns under the Federal Rules of Civil Procedure. The episode highlights how the absence of standardized metadata fields for linked documents presents new challenges for eDiscovery professionals—and why it’s time for the legal community to rethink traditional assumptions about attachments in modern communication.

This episode is a must-listen for litigators and eDiscovery professionals navigating class actions or complex business disputes. Join Kelly as she shares practical strategies for addressing this emerging issue, ensuring your ESI protocols account for today’s data realities, and preparing your team for the future of eDiscovery.

𝐍𝐢𝐜𝐡𝐨𝐥𝐬 𝐯. 𝐍𝐨𝐨𝐦 𝐈𝐧𝐜., 𝟐𝟎𝟐𝟏 𝐖𝐋 𝟗𝟒𝟖𝟔𝟒𝟔 (𝐒.𝐃.𝐍.𝐘. 𝟐𝟎𝟐𝟏)
eDiscovery Assistant Blog
eDiscovery Assistant Website
eDiscovery Assistant Free 7 day Trial (no credit card required)

Have questions for Kelly or have a specific decision you would like us to cover? Reach out at hello@ediscoveryassistant.com! 

Thank you for tuning in to Case of the Week with Kelly Twigger. If you found today’s discussion helpful, don’t forget to subscribe, rate, and leave a review wherever you get your podcasts. For more insights and resources on eDiscovery, visit eDiscovery Assistant and explore our practical tools, case law library, and on-demand education from the eDiscovery Academy. Join us next episode as we break down another important case shaping the future of eDiscovery.

Transcript

This week on our #CaseoftheWeek series  is 𝐍𝐢𝐜𝐡𝐨𝐥𝐬 𝐯. 𝐍𝐨𝐨𝐦 𝐈𝐧𝐜., 𝟐𝟎𝟐𝟏 𝐖𝐋 𝟗𝟒𝟖𝟔𝟒𝟔 (𝐒.𝐃.𝐍.𝐘. 𝟐𝟎𝟐𝟏). Our issue this week is a really important one, is going to have some massive technological implications for collections and review platforms. It’s one that we’re really going to need to pay attention to. It’s also one that we’re going to need folks to weigh in on and figure out solutions to.

The #CaseoftheWeek presents this issue, essentially how parties have to collect and produce documents in emails that are hyperlinked instead of being physically attached to emails as what we commonly referred to as an attachment. In Nichols, Noom used Google Apps to manage its email and documents. If you’re not familiar with Google Apps, it works a lot like Teams if you’re now using Teams with your organization where you create documents. The documents are stored in one location in Google Apps or stored on Google Drive. The emails are stored in the Gmail application and then parties share links to the documents back and forth, version tracking is done via the actual application and stored in Google Drive.

The question becomes, when you produce documents that have links to documents in them versus actual attached physical documents to them, that tools do not generally collect, what is the party’s obligation to provide those hyperlinked documents?

It’s going to be very important going forward because we’re going to see that the current collection tools that are designed are not dealing with this issue. We also don’t necessarily have a way to deal with it in the review platforms unless we have standard metadata fields that allow us to link documents back together with what we would call their “parent email”. Let’s talk specifically about the Nichols’ case.

This Nichols’ decision that we’re looking at is a motion for reconsideration from March 11th. 2021 Judge Katherine Parker is the United States magistrate judge for the Southern District of New York, and, you know, from eDiscovery case law in general that the judges in the southern district of New York are very well educated on ESI related issues. It is a hotbed of ESI issues and this decision from Judge Parker is well thought out and considered. It raises some challenges as to what the court’s role is in these kinds of technological issues and what the party’s obligations are to plan for that. We’re going to talk about that a little bit in the takeaways. Let’s talk about the case.

Nichols is an ongoing class action litigation alleging that Noom failed to allow subscribers to cancel their subscriptions. It was filed in May 2020, and as the court notes in the motion for reconsideration, both sides have very knowledgeable counsel on ESI related issues. The parties began to negotiate an ESI protocol, but disagreed on some major aspects of it, which required multiple conferences with the court. One of those aspects was the collection of documents in the Google App Services. Noom agreed to collect and did collect data from multiple sources, including Gmail, Google Chat, Google Drive, Google Calendar and several other reporting tools and databases. They also agreed to produce a long list of metadata.

In November, six or seven months after the case was filed, the parties advised the court had agreed to Noom’s use of Google Vault (which is Google’s extraction tool for its services) to collect documents from Google Drive, even though file path metadata would not be available for documents that were collected using Google Vault. File path metadata is really important. If you want to understand where data came from and you want to be able to link any kind of documents back together again.

The parties disagreed on the use of Google Vault  to collect emails from Gmail, and in November, the parties asked Noom to use a forensic tool called FEC that would allow the links in the Google Mail to collect the associated documents and provide metadata in the same way that attachments are normally handled with documents. We’re really looking here at the difference between I have an email and there’s a word document attached to it, a normal collection tool will attach that word document to the email, it’ll maintain a parent child relationship, there’ll be a link between the two documents and you’ll be able to keep that relationship within your review platform. Where you have a hyperlink instead of an actual attached document is where we have the issue.

The plaintiffs here asked the court to order Noom to use a forensic tool to collect information instead of using Google Vault. On the initial motion, which was prior to this motion for reconsideration, Noom put in an affidavit, an ESI expert that stated that Google Vault was an industry accepted tool and that it was a reasonable collection tool that was used by the majority of Google’s business clients.

They also stated that the collection of emails using FEC, the forensic evidence collection tool, while collecting documents in Google Drive, so two separate collections. If we collected Google Drive and we use FEC to collect hyperlinked documents from email, it would result in a significant number of duplicates in its review population that could not be culled through deduplication. There’s no specifics on why they couldn’t be culled through deduplication, I’m guessing the hash values must have changed when you collect them because those are all created by your processing tools.

Following that original motion, the court allowed Noom to use Google Vault and stated that if there were certain documents that were discovered in the production that contained hyperlinks for which the corresponding hyperlinked document could not be located or identified (i.e., the plaintiffs couldn’t find it from the documents that were produced from Google Drive) then the plaintiffs could raise the issue with Noom, and Noom would be required to provide the document or the Bates’ number. Noom stated that from the start they were willing to do this for a reasonable number of documents.

Fast forward to Noom uses Google Vault to collect documents from Google Drive and from Gmail and produces those to the plaintiffs. The plaintiffs look at the production and realize that there are thousands of documents that contain hyperlinks to other Google Docs, and they have no way to be able to link the documents that may have been produced from Google Drive back to those emails.

Essentially what happened here is that Noom collected emails, reviewed, and produced those emails without producing the hyperlinked attachments that would have been documents. There’s a separate issue of there being other kinds of hyperlinks that might not be connected, but let’s just say with them as documents for now. Noom produced emails with hyperlinks to documents that were not attached. Noom separately produced documents from Google Drive some of which have been attached to these emails, but they did a separate analysis from our responsiveness production perspective as to whether or not these should be produced. Ostensibly, you’ve got emails over here that were produced to the plaintiffs with hyperlinks, with those hyperlinked documents were not produced because they were decided over here that they were potentially nonresponsive.

That’s the practical issue that we’re dealing with here. It turns out that we’re not dealing with a few documents or a reasonable number of documents. We’re talking about thousands of documents. Now you’ve got a situation where the plaintiffs have to go through and manually identify, or write some kind of computer script to identify, all of the cases where hyperlinked documents exist that they’re unable to piece back together from the Google Drive documents. That’s thousands of documents. That’s above and beyond what the parties agreed to deal with after the court’s initial order that they could use Google Vault.

Plaintiffs come back to the court and they argue to the court that, one, we want the court to clarify their previous orders and rulings regarding the defendant’s production of documents linked to Google Drive documents via hyperlink. They ask for the court to reconsider the prior rulings that Noom be permitted to use Google Vault and to the extent that documents were identified that the plaintiffs came back to Noom and said, “we need to have the Bates’ numbers for these documents.” Basically, they say to the court, “we need you to revisit your earlier opinion.”

In this motion for reconsideration, the plaintiffs asked the court to again require Noom to use the forensic evidence collector, which is a tool called FEC from Metaspike, to recollect Google Drive and Gmail documents so that any hyperlinked documents are also pulled as part of the document family. We’re looking at using a tool that would allow those documents to be created as attachments in the way that the standard eDiscovery collection process has been done.

The second thing the plaintiffs ask for is, if you’re not going to require them to use FEC to recollect and give us the information, then please require them to write a custom script that would allow Google Drive to export the links for those documents and produce them as attachments. It would essentially create a program using Google’s application programing interface, their API, which would extract the links from responsive Google Drive documents, retrieve those linked documents and produce them as attachments. With regard to that request, on the specific program, the plaintiffs estimated it would take only one to two weeks to write a program to extract the links.

What’s really key here, though, is on the plaintiff’s motion for reconsideration, the plaintiffs did not place any information about the time or cost that be required for processing, deduplication and re-review of documents that had already been produced in its motion. The plaintiffs argue that the hyperlinks are akin to attachments and should be produced as part of a document family, and without the metadata linking the underlying hyperlinked Noom document to the document containing the hyperlink, they’re unable to determine the families of documents. Plaintiffs are also concerned that some of those documents may not be produced at all. We kind of talked about that a little bit, right, that if you look at the Google Drive document, separately from the email, you may decide the documents over here are not responsive when typically, they would have been attached to a responsive email and in a normal attachment family situation, a document that’s attached to a responsive email, would be produced. We typically do not leave out non-responsive attachments.

On the motion for reconsideration, the court’s analysis was really the following. First, the court acknowledged that, and this is a quote, This is important. “The issues raised by plaintiffs raise complex questions about what constitutes reasonable search and collection methods in 2021. When older forms of communicating via emails and documents with attachments and footnotes or in notes are replaced by emails and documents containing hyperlinks to other documents, video, audio or picture files. It also highlights the changing nature of how documents are stored and should be collected.”

What the court’s saying in this particular paragraph is really two things. One, “we’ve got new technological developments that haven’t been considered yet, either by tools that are existing and commonly used in the marketplace or by the rules and how we define documents under rule 34.” It’s really important to consider that language, and it is also important because what the court decided here will have a dramatic impact on eDiscovery going forward, that it be kept in context for how the court looked at.

The second thing the court did was look at the language of the ESI protocol, and it stated that the parties had not specifically treated hyperlinked documents as attachments and found, quote, “that there was no meeting of the minds on whether hyperlinks were attachments. And this court, when entering the order, did not view hyperlinks to be attachments.”

Here’s what the court says about hyperlinks as attachments. They do not agree that a hyperlinked document is an attachment, but that it might be akin to an attachment and here’s what the court says and quote, “When a person creates a document or email with attachments, the person is providing the attachment as a necessary part of the communication. When a person creates a document or email with a hyperlink, the hyperlinked document/information may or may not be necessary to the communication. For example, a legal memorandum may have hyperlink to cases cited therein. The court does not consider the hyperlinked cases to be attachments. A document may also contain a hyperlink to another portion of the same document. That is also not an attachment. A document might have a hyperlink shortcut to a SharePoint folder. The whole folder would not be an attachment. These are just examples. An email might have hyperlinks to a phone number, a tracking site for a mailing shipment, a Facebook page, a terms of use document, a legal disclaimer, etc. The list goes on and on. Many of these underlying hyperlinked documents may be unimportant to the communication.” That’s a very valid point from the court, but the flip side of that is that some of these underlying hyperlinked communications may be extremely relevant to the communication. The balance here is one that the court looks at from the considerations that are present in the federal rules, proportionality and cost considerations based on what’s already been done in the matter.

But, from a practical perspective, there are massive implications here for any kind of party. This is a class action litigation, but there are many sophisticated business disputes going on right now with companies who use Google Apps. Microsoft Teams, in which you share links to SharePoint documents via Teams internally, are also going to have a very similar problem and this needs to be resolved as to how we’re going to deal with this issue and eDiscovery. We’ve talked previously on the #CaseoftheWeek about the fact that we don’t have a complete collection strategy for all the ways in which data is available through Microsoft Teams. The same is true with Google Apps.

The court also found that it was entirely speculative how many underlying documents were relevant and material to the case, and that the current process that it had outlined, allowing Noom to use Google Vault and having plaintiffs identify documents with links that needed to be provided was appropriate to allow the plaintiffs to evaluate their production and determine if there was an additional need for targeted pulls. The court also noted, as I mentioned, the proportionality and FRCO Rule 1 concerns of costs and delay, because the plaintiffs here were asking for an entirely new collection of emails and Google Drive documents that had already been collected, they had already been primarily, mostly, reviewed for relevance and production, and that the plaintiffs had already agreed that Vault was an acceptable tool for the drive documents. The court basically denied the motion for reconsideration. The court also rejected the plaintiff’s argument that Noom should be required to write a script.

One other thing that’s really key to note here, and I mentioned it earlier, is that Noom argued on the motion for reconsideration about the redundancies and the additional costs associated with having to recollect the data using the FEC tool. They argued a few different things. One, that because they would be recollecting the same link from dozens of emails, which happens all the time, we see the same attachment attached to multiple emails in a production, that they would be pulling that same document tens, if not hundreds of times in some cases, that it would increase the review population, complicate de-duplication, delay production and impose additional costs on Noom to the tune of about $180,000.

Plaintiffs really had no ability to counter the amount of cost associated with that because they don’t know that much about the documents or how many duplicate duplicates there would be or any of that information. It’s another situation in which an imbalance of knowledge about the data that we’re discussing leaves one party at a disadvantage to be able to argue in front of the court.

Here’s what the court ultimately comes down with on its ruling to deny the motion for reconsideration, and this is a quote, “The court acknowledges the inherent tension between the value and efficiency in creating an ESI protocol up front that addresses all potentially foreseeable issues on the one hand and getting discovery underway in the case on the other hand. The existing protocol, together with the court’s workaround to address the plaintiffs concerns for those key documents where they need more information about the hyperlinked documents, strikes an appropriate balance based on the needs of this case, and as reported at the most recent conference, the parties have already successfully utilized the court’s procedure.” With that, the court denied the motion for reconsideration.

What are our takeaways? Well, if you are in Litigation Support or you are handling data, you are cringing right now with the practical implications of this decision and the need to be able to plan for this in your protocols. We talk a lot on this #CaseoftheWeek about ESI protocols. We’ve written a series of posts on our eDiscovery Assistant blog on our on ESI protocols and what needs to be included in them and this will be yet another piece that will write up for that blog.

Essentially, as we’ve talked about, parties need to know and understand the systems that they are dealing with before drafting an ESI protocol. This issue of hyperlinked documents is going to be more and more apparent as we move through — with the onset of the pandemic. Many, many, many companies moved to Microsoft Teams. Microsoft Teams works with linked documents in the same way that Google Apps works with with linked documents. We’re going to have to start structuring protocols that specifically call out how those links are to be treated and if there is a document, a physical document that a hyperlink is included in an email with substantive content versus simply a hyperlink out to a Web based link or something else, a link to a YouTube video or otherwise, then that information needs to be produced as an attachment. We’re going to have to break down individual examples of how different things can be attached as hyperlinks within a document and how those pieces of information are going to be treated for purposes of collection, review and production. It’s a whole new way of thinking about data, and it’s not one that is specifically addressed by the federal rules of civil procedure.

Practically speaking, I don’t think the court is the one that should be deciding whether a hyperlink constitutes an attachment. I definitely agree here with Judge Parker that there are a lot of proportionality and cost considerations, and that the plaintiffs were at a disadvantage here, not having any data to disagree with the court at the point at which they agreed to allow the use of Google Vault. They really didn’t have a basis to disagree because they hadn’t seen any documents at that point. They did not know the scope of the problem that would be considered and once they identified that scope and came back on a motion for reconsideration, the court looked at, hey, well, look, you’ve already been down this road. You’ve already spent all this money. We don’t even know how many of these documents are going to be relevant. All of those are great bases on the motion for reconsideration, but it still leaves the plaintiffs in this particular case at a huge disadvantage.

Again, this issue is not one that is just specific to class action litigation. We are going to see this issue in many, many business disputes among multiple sophisticated parties.

From a technical perspective, the plaintiffs in this case, when they’re receiving this production, are not receiving what they would normally receive in a collection where documents will be physically attached to an email. The question becomes, under the Federal Rules of Civil Procedure, whether they are, in fact receiving the value of the same information that is available to Noom here, to the defendant. The Federal Rules of Civil Procedure require the receiving party, not plaintiffs, just happens to be the plaintiffs here, that the receiving party gets the same information that is available to the producing party. Here you lose metadata and the ability to match up the documents from Google Drive. You’re never sure whether you actually have all the attachments to an email and you have no ability to review the attachments as associated to an email in a review platform. From a perspective of creating the story and understanding the facts and being able to prepare for depositions, that is really crucial. That is very difficult thing to have to deal with from the plaintiff’s perspective here.

As we all know, part of the story of reviewing documents and how we piece things together is who sent what to whom and when and what changes were made on different versions. How all of that is dealt with when it comes to these constantly updated systems, both with Microsoft Teams and with Google Apps, is something that’s going to have to be considered. I’ve had discussions with folks about how each version is going to be managed in these systems and what versions need to be produced from an eDiscovery perspective.

If you see in the links to the #CaseoftheWeek this week, you’ll see two articles. One is from Doug Austin at eDiscovery Today on his write up of this decision in Nichols versus Noom. The other is an article from Craig Ball on his blog, Ball in Your Court, and Craig raises two great points in his article that are additional practical considerations for hyperlinks. This is a big issue that we’re going to have to sit down and work through all the challenges on and try and figure out, but Craig’s points are what if the content at the link no longer exists? What if you have an email with a hyperlink to a document? And in the time since that document was created and that email was sent, the document was taken down and no longer exists. What are you going to do then? Ostensibly, under the Federal Rules of Civil Procedure, if the content no longer exists, the content no longer exists. There’s no sanction for that unless it was destroyed after a duty to preserve went into play.

The second point that Craig raises, which is also a good one, is what if the content of the target has changed since it was linked? This happens all the time, right? When in Google documents, you can go in and make changes to a document that you have access to at any point in time, and that will show up as the version of the document that could be collected. The question becomes, is the version that’s collected at the hyperlink the one that was available as of that date, is that even possible from a collection perspective? There are a lot of complications technically here that this issue raises.

There’s one further takeaway for you from this case that comes to mind for me, and that is that Rule 34 requires a production of documents in two ways. Either as they are maintained in the ordinary course of business or by request. It is always been the case that how ESI is maintained in the ordinary course of business is completely dependent on the organization and the systems in which data is maintained. That phrase in and of itself needs clarification as it pertains to ESI. There needs to be more guidance from the rules and from the courts on what producing information as they’re maintained in the ordinary course of business means. Rarely have I seen, in twenty-five years of practicing, that information was produced by request and so more guidance is absolutely needed on what ordinary course of business means in terms of the manner of production.

As I mentioned, this is a really important issue that we’re going to have to have more clarification on, not only from the courts, but in the meantime, you need to make sure that when you’re engaged in litigation, that you understand that if you’re dealing with Teams, if you’re dealing with Google Apps, if you’re dealing with any system in which documents are now attached as hyperlinks as opposed to as standard attachments where the the word document or the Excel file or the image are physically attached to the email that is sent to you, how are you going to deal with those? You need to look at language in your ESI protocols and plan for how that information will be provided to you and make sure that both sides have the capabilities from a collection perspective to provide information in that way.

That’s our #CaseoftheWeek for this week. Please join us next week as we’ll pick up a new issue. Thanks again for joining me this week and we’ll look forward to seeing you next