Episode 108: Is an individual Slack Message Considered a Document under FRCP 34?

In Episode 108 we cover a key decision in ediscovery case law on collaboration platforms because of its ruling on how the court treated a conversation thread under Rule 34’s definition of a document and the context required for production. Read on to see whether a message on Slack is a document itself, or what the producing party was required to provide and focus on the takeaways provided from CEO Kelly Twigger.

Introduction

Welcome to this week’s episode of our Case of the Week series brought to you by eDiscovery Assistant in partnership with ACEDS. eDiscovery Assistant is a practical and strategic resource designed to help lawyers and legal professionals supporting them to understand and leverage the value of ESI.

My name is Kelly Twigger. I am the CEO and founder at eDiscovery Assistant, as well as the principal at ESI Attorneys. If you haven’t yet had a chance to grab our 2022 Case Law Report, download a copy of that for your perusal.

This week’s decision is an important one because it provides a bit more clarity around Rule 34’s requirement to produce documents as it pertains to collaboration tools, text messages, and Slack as well as Teams data. All of those are discussed in this decision, although the actual motion to compel focuses on Slack data. We’ve discussed multiple times on Case of the Week that Slack, Teams, instant messaging, and text messages are all becoming very prominent sources of ESI, and that planning for understanding them and knowing how to deal with them in discovery is crucial.

Background

Let’s dive into this week’s decision from Lubrizol Corp. v. IBM Corp. This is a decision from May 15th of 2023 from United States Magistrate Judge Jennifer Armstrong Dowdell. Judge Dowdell has been on the bench just since August of 2022, and this is the second decision that she has in our eDiscovery Assistant database. Welcome to the fray, Judge!

Facts

We are before the court on a motion to compel the production of Slack messages in a breach of contract action. Lubrizol alleges that IBM breached a contract between the parties and committed fraud and various torts in connection with a project to implement a new enterprise resource planning software. This particular decision is on referral from United States District Judge David Ruiz to Judge Dowdell. Lubrizol is asking the court here to compel IBM to produce complete conversations for any Slack thread containing at least one responsive message.

It’s not specifically articulated in this decision, but it’s pretty clear that the parties came up with search terms and that IBM ran those search terms against its Slack instance and produced messages that were responsive to those search terms. We’ve talked a little bit before about how Slack works, but Slack is set up to work in channels and there are really two ways to communicate. You can communicate via a channel in which you put multiple people on one channel — generally to communicate about a specific topic — or you can use direct messages which are from one person to another within Slack. If you’re using enterprise Slack or your organization has enterprise Slack, you can be talking about thousands of channels and thousands of different conversations, or even hundreds of thousands of different conversations. It can be very complex. If you’re using Slack on a small scale, try to amplify it to using for 1,000, 10,000, 100,000 employees, and you start to realize the complexity of what you’re dealing with. Slack is a free tool that you can download and start using to get the feel of it.

In this particular case, the parties sat down and tried to negotiate what Lubrizol wanted after an initial correspondence with the Court about IBM’s production. The Court basically sent them back and said — you guys try and figure this out a bit before you come back to me. Following those negotiations, Lubrizol modified its request based on the number of the messages in the thread. Specifically, Lubrizol sought 1) the entire thread conversation for any conversation containing 20 total messages or fewer and hitting on one responsive message in that conversation, and 2) for any conversation with one responsive message where there are more than 20 messages in the conversation, IBM should be required to produce the 10 messages preceding and following any responsive message.

So two different situations. And they really decided that the cutoff was 20 messages within a conversation. They call them threads in Slack. So they’re actually called conversation threads. And in Slack, you can reply generally in a channel to someone, or you can reply in a thread to that specific message. And often replying in the thread is a good way to keep the topics of that particular conversation together. But people use Slack differently, so it very much depends on whether people respond in conversation threads or not. Understanding whether your client does and how the employees use Slack is going to be important to how you make determinations about what Slack data needs to be reviewed and produced and what you should provide in this agreement. You can learn this by talking to custodians, but in reality you need to see the data to know how it’s organized.

IBM informed the court in response to this motion that it had reviewed all of the Slack messages that hit on any of the parties agreed upon search terms, as well as the 10 messages before and after any message that hit on a search term. They reviewed 10, but not 20. That’s the difference of where we are right now with the longer thread lengths. After review, IBM produced any message in that window that provided context for the relevant discussion, even if the message did not hit on a particular search term, but it was in their discretion as to how many messages before and after the responsive hit were produced. Lubrizol wants more context.

IBM argued that adopting Lubrizol’s proposal would require IBM to produce irrelevant materials in violation of the Federal Rules of Civil Procedure and impose an undue burden on IBM. Basically, they argued that additional production was not proportional to the needs of the case.

Analysis

The court starts with Rule 26’s requirements of relevance and proportionality, and that the party moving to compel bears the burden of demonstrating the relevance of the requested discovery. Of course, that’s always hard unless you have documents or testimony that suggests the full context of conversation is not being provided.

The only issue before the court here is whether IBM should be required to produce additional Slack messages to provide further context for the messages that it had already produced. IBM argues that it had already produced all the Slack messages that it’s required to under the Federal Rules and that the additional materials that Lubrizol is seeking were irrelevant and unduly burdensome.

The Court states the issue as this: whether each individual Slack message should be treated as a discrete document under Rule 34, or whether a court should view an entire Slack channel as a single continuous document. This is an issue of first impression for the Court. This is an issue of first impression in case law. We haven’t seen anything analyzing this issue as it pertains to Slack from any case law in eDiscovery Assistant. IBM argues that each message is a discrete document because the messages are stored on the Slack system in files known as JSON files. That’s the file type for which individual Slack messages are stored on that platform. Lubrizol doesn’t dispute that Slack messages are stored individually as JSON files, but it argues that a conversation should nonetheless be treated as a single document because participants in a Slack conversation view the entire conversation at once, even if the conversation spans months or years.

As a matter of first impression, there’s no case law on point for the court to consider here, so the parties argued how Slack conversations relate to other types of ESI, namely email and text messages. IBM sticks with its argument that each message is stored separately and therefore each message is a separate document under Rule 34, and therefore no additional context is required. Lubrizol argued that Slack messages are more analogous to emails or text messages and further asserted that parties are regularly required to produce the entirety of an email or a text message conversation, even if portions of the document are irrelevant.

Neither one of those arguments is exactly right when we think about email or text messages, how they exist electronically, and how we produce both of them. But it is true that in using email and in producing email, we typically have to produce email threads, whether or not we produce them in a threaded context or individually. Anytime emails follow each other and the top document is the one you have to produce, all of the emails that were preceding that need to be produced as well. The parties may negotiate whether or not irrelevant emails can be redacted, but that’s a separate issue than what we have here.

The court rejected IBM’s position that each Slack message must be treated as a separate document like hard copy documents in the same box and instead states that Slack messages are most comparable to text messages rather than hard copy documents. The court notes that different hard copy documents “are not originally created in a single box and their subsequent placement in the same box may be the result of sheer happenstance.” In contrast to hard copy documents, which are scattered all over, all of the messages in a particular Slack channel appear in a single conversation and a participant in a conversation can view all of those messages at once, regardless of when they were originally sent.

It’s really difficult in this context to compare a hard copy document to an ongoing text message thread or a Slack message thread, because we never respond to hard copy documents in the same way that we do with electronic communications like email, text messages, or Slack.

Even though the Court finds that Slack messages are not the same as hard copy documents, that doesn’t really resolve the motion because different courts have taken different approaches with respect to text messages. The Court notes that some courts have suggested that a party must produce the entirety of a text message conversation that contains at least some responsive messages. Other courts have held that the producing party can unilaterally withhold portions of a text message chain that are not relevant to the case. Finally, other courts have split the baby, allowing a party to produce messages that provide sufficient context and have also allowed the parties to redact portions of a message that were not relevant. We’ve got three different positions here on how to deal with text messages, which the Court has found are most aligned with Slack messages.

The Court here agreed with Lubrizol and required IBM to produce surrounding messages, even if IBM believes that some or all of those messages are not relevant to its case. The court gives three reasons for that position. First, the court notes that there is a legitimate dispute regarding whether all of the messages that IBM has withheld are truly irrelevant. In particular, the court notes that some of the messages relate to similar work that IBM has performed or is performing for at least one other client. Lubrizol argued that such communications are relevant to its arguments and that IBM misled Lubrizol about how the project would be staffed, how IBM managed the project, and whether IBM had the expertise it claimed when it pitched the project. The court notes that it’s unclear what proportion of the messages encompassed by Lubrizol’s proposal relate to other similar projects, but that it appears to be undisputed that at least some of the messages that IBM has not produced relate to those projects, and that fact weighs in favor of granting the motion to compel.

The second thing the court states is that the very existence of the protective order substantially decreases any concerns regarding production of reportedly irrelevant messages that might otherwise be sensitive. Those messages might include information about other IBM projects or communications about the personal lives of IBM employees.

Third, the court finds that IBM has not established that it would be unduly burdensome for it to comply with Lubrizol’s proposal given the scope of this case, which the Court notes, involves a substantial dispute between two large commercial parties. IBM, on this point, tried to argue that Lubrizol’s original request would be “to expand its current production volume by nearly 60 times.” The Court found that IBM didn’t provide any information regarding the number of messages that were encompassed by Lubrizol’s revised proposal of the 20 messages or the burden and expense associated with complying with that proposal. (We’ve talked about this many times on Case of the Week. If you don’t put the facts before the court on your proportionality argument as to the cost and burden that you are arguing is disproportionate, you will not win.)

Based on those three arguments, the court found that the production of the additional Slack messages was not unduly burdensome or disproportionate to the needs of this case. Not surprising. IBM also raised the point that a similar ruling should apply to Lubrizol’s production of its Teams messages, as Lubrizol had originally produced those messages individually without any context. Lubrizol agreed to abide by the same protocol and that it would produce the 10 messages proceeding and following any Microsoft Teams message in its possession custody or control that was responsive to IBM’s discovery request or the entirety of any Microsoft Teams conversation containing 20 or fewer messages in total. That’s just essentially the same agreement that the court is requiring IBM to engage with Slack.

The final decision from the Court is to order IBM to 1) produce the entirety of any Slack conversation containing 20 or fewer total messages that has at least one responsive message and 2), the 10 messages preceding or following any responsive Slack message in a Slack channel containing more than 20 total messages. That’s exactly the same as what Lubrizol came to the court with after the parties negotiated. The Court required that both parties do that within 28 days. That’s a fast turnaround.

Takeaways

What are our takeaways here? First, this is a key decision on an instant messaging platform like Slack. While it’s not going to be precedential, this decision is the first to recognize that Slack messages are not individual documents under Rule 34 comparable to a hard copy document, and instead Slack messages are most comparable to text messages and require context. Keep in mind that this is a factually specific ruling, and that the facts of your case may change what the scope of context is that’s necessary. That required context may be larger than 20 messages and it may be smaller than 20 messages, and you’ll need to question whether the production of full threads from Slack that hit on search terms are going to be required. This is not a different ruling than what courts already require with email threads, but the technology is different and the potential for moving across topics in threads in instant messaging is much more prevalent than it is in email. It’s just human nature. And that’s really why you have to think through these issues in detail.

The second takeaway is with respect to search terms. We’ve talked about search terms so many times on the Case of the Week and the need to make sure that you are thinking carefully before you enter into an agreement on search terms. The fact that the issue here is context around search terms highlights the importance of picking search terms based on the data and making sure that the producing party is reviewing data before proposing search terms. We’ve talked about why the producing party should be the party to identify what the search terms are that identify documents responsive to the request for production. This is not something that the other side who does not have the data should be arbitrarily picking out. In this case, where you’ve got two sophisticated commercial parties on a breach of contract and they both have data from each other, you’re going to have more of an opportunity for search terms to overlap, but the two parties still should be doing their diligence on what search terms are going to find responsive documents independently, and then moving together to cooperate and finding a full set of search terms based on individual requests for production.

Make sure that when you are engaging in your search term negotiations, you are documenting all of that process. That way, in case you find out that the other side is not providing all of the search terms or has not done the work to identify search terms, you have a basis to go to the court with that information.

Next takeaway goes back to the ESI protocol. eDiscovery is now very detailed and it requires attention to very specific details for each source of ESI, just as we saw here with Slack in this decision. You need to understand these sources before you have a case that requires you to identify the issues for a particular matter so that you can make the arguments effectively and draft your ESI protocol (or subsequent agreements if you do them separately appropriately). We saw in the Twitter v. Musk case where they had a specific protocol for short messaging. You can always negotiate those things separate from an ESI protocol, or you can amend your ESI protocol if you put the right language in there and get it approved by the court.

The final takeaway; get into the data. This applies whether you are the producing party or you have received a production. If you’re the producing party, get into your data and be prepared to show examples of it to bolster your argument. Here, IBM was not able to do that effectively for the court. The court doesn’t mention what they did provide, so we can’t know the full scope of what was presented. But it wasn’t enough. Lubrizol, on the other hand, was able to argue effectively that data showed relevant messages existed beyond the context produced by IBM. Since it was IBM’s burden, that was enough to prevail.

Know your data. If you are the receiving party, review the data for these issues as soon as you receive it. Don’t wait, because you’ll prejudice your arguments with the court and you’ll lose valuable time with depositions and fact development. When you have to go to motion practice, it takes you a longer time to get that information and then you’ve already engaged in those depositions, or you’re getting close to the end of discovery and you’re just now getting that information. It will prejudice your case and your client if you wait. It’s expensive to go to motion practice, and it’s often unnecessary if you can demonstrate to the other side via data that your arguments will prevail. But if you can’t convince the other side, and you still have to go to motion practice, you will have done the bulk of the work done to substantiate your arguments for the court.

Conclusion

That’s our Case of the Week for this week. Thank you so much for joining me. We’re back again next week with another decision from our eDiscovery Assistant database. As always, if you have a suggestion for a case to be covered on Case of the Week, drop me a line. If you’d like to receive the Case of the Week delivered directly to your inbox via our weekly newsletter, you can sign up on our blog. If you’re interested in doing a free trial of our case law and resource database, you can sign up to get started.

Thanks so much, and have a great week.