This is the first of a three part series of tech tips on Slack.
You’ve never heard of Slack or you’ve never used it, and suddenly you’re faced with it from a client or needing to ask for data from it. This tech tip lays out what you need to know and each of the considerations for dealing with Slack data. If anything you read here boggles your mind, you’ll want to get help, whether that’s internally (litigation support, discovery counsel) or externally (service provider, vendor, discovery counsel). Missing out on Slack data can preclude you getting exactly what you need for your case.
So what is Slack? Slack is a workplace messaging platform where teams collaborate in real time. Instead of long email chains, conversations happen in channels (topic- or team-based spaces), direct messages (DMs), and group DMs. People reply in threads to keep side conversations organized, add emoji reactions to signal status, and share files alongside the chat that discussed them. Many orgs also use huddles (quick audio/video), clips (short screen/video captures), and canvases (docs embedded in Slack).
Here’s a screenshot of what a Slack instance looks like:
Historically used across venture-backed startups, SaaS and cloud companies, engineering/product/design orgs, Slack has become much more mainstream since Covid. The platform is very commonly used within organizations that also have Teams, or it’s the only platform, and it can be distributed to teams of all sizes from 2-10,000 users. For those clients, Slack is a primary system of record. That makes it ESI, and handling it well (scope, collection, form) supports your story; handling it poorly will both undermine your credibility and potentially cause you to lose out on key evidence.
What to Do When Your Client Uses Slack and It’s a Source of ESI in Your Matter
You need to understand how your client’s Slack instance is set up and how their users leverage it. Everybody leverages the platform a little bit differently, and that will vary from user to user (so add that to your custodian checklist for this matter). The best way to learn is to ask for a walkthrough of the architecture: workspaces; which channels actually matter (public and private) for your matter; how heavily DMs and group DMs are used; whether threads carry the real conversation; and whether huddles, canvases, or clips are part of day-to-day work. Using search terms to search will create “hits”, but that is rarely the whole story—surrounding messages and thread context carry intent and it’s your responsibility to determine how much context is needed to provide responsive data. Remember when you sign those discovery responses, you are stating under FRCP 26(g) that you conducted a “reasonable inquiry”. Having to go back multiple times costs your client time and money and if the court is involved, they’ll know what you didn’t know or do.
Next, understand what plan they are on with Slack (Business+ or Enterprise Grid) and whether discovery exports are enabled. If not, does the client have a partner they use to collect data from Slack? If they can’t export, current case law suggests you may have an argument that you don’t have possession, custody or control of the data. Pro tip: Those rulings are suspect in my opinion and unlikely to hold up, so you can make the argument (you’ve got case law to support it) but be prepared to produce from Slack if you lose.
Once you know the lay of the land, you need to lock down how the client handles retention and how to implement a legal hold on Slack data. Are messages auto-deleting? Can channel-level retention be suspended quickly? Do third-party apps create or remove content you need to preserve? If you can’t freeze deletion now, escalate and fix it, then document when and how you did. Perfection is not the goal, but taking action to stop deletion once your duty to preserve has attached is critical.
Now you need to define custodians by source. Slack custodians are not necessarily your email custodians. Identify the people who “live” in relevant channels and DMs and build a Slack-specific list so the collection isn’t blind to where work actually happens.
When the Opposing Party Uses Slack
When you have to request data from Slack, knowing how it works is critical to drafting focused and reasonable requests. The only way to do this effectively is to have a specific discussion in the meet and confer about Slack and ask the questions you need to that stem from the discussion above. Who are the relevant custodians using Slack? What channels did they use that might have relevant messages? How long is data kept? What are the date ranges for each custodian using Slack? Etc. That way you can tie your requests to issues first, channels second, and dates third.
Name the channels/DMs most likely to hold key conversations. To understand context, have opposing counsel review the data and propose and a fixed context window (e.g., 10 messages above/below a hit or full threads wherever a hit appears), then test that with produced data until you see an example that doesn’t fit. Make sure any language you agree to on scope says that you’ll meet and confer if the initial boundaries don’t work (meaning 10 messages before and after isn’t sufficient for some threads/exchanges/)
You’ll need to anticipate PCC/licensing objections as outlined above. If the opposing party isn’t on an export-capable plan, propose practical solutions: a temporary license upgrade, vendor-managed exports, or a small pilot to test sufficiency. If necessary, offer cost-sharing where proportional to remove the “we can’t” defense and keep the scope grounded. Make sure you’ve offered some options before you go to the court, and for heaven’s sake make sure the court understands the imperative of this data to your case, tied to specific allegations, and provide whatever support you can to bolster your motion.
The best way to determine the boundaries mentioned about is to ask early for a sample set from a few named channels and dates to validate completeness, threading, and metadata before anyone scales up.
Case law on Slack issues tells us that specificity and feasibility get traction; blanket demands and hand-waving don’t. Showing up with a concrete, proportional path shapes the order you’ll get. You have to be prepared to educate the court on how Slack works and why you need what you need. Showing up with jargon that the court can’t wade through won’t get you what you want. Be a teacher.
How the Courts View Slack Data
Case law is instructive on what courts say is discoverable from Slack. They want conversations, not fragments. Opinions have endorsed fixed context windows around chat hits, recognized Slack-specific custodians, and treated export capability as relevant to possession/custody/control. See e.g., Vaughn v. Solera Holdings.
Part 2 in our Tech Tip Series on Slack will look at what to include in an ESI protocol around Slack to ensure the parties understand and meet their obligations.
Learn more about Minerva26.
