This is the second part of a three-part series of tech tips on Slack as ESI. You can read Part 1 here.
When Slack is a key platform for evidence for your case, making sure what the parties agree to is a key element to include in an ESI protocol. That way, you can argue effectively to the court if things go off track.
Here’s a list of what you want to make sure is included in your protocol, and conversely, what you’ll need to discuss at the meet and confer about discovery from Slack. Keep in mind that discovery, and Slack discovery in particular, is an iterative process that you want to be able to revisit as you learn more.
Scope & context. List named channels/DMs, date ranges, and Slack-specific custodians. Memorialize that responsive chat includes the agreed context window (or entire threads for messages containing hits). Include a mechanism to expand the channel list based on what the sampling reveals. Keep in mind that agreeing to a random number of messages before and after, without looking at the context yourself, may leave you limited. Courts tend to hold parties to what they agree to in a protocol.
Form of production. Confirm the format you need with your litigation support, whoever is handling the Slack data, or with whatever platform you’re loading it into. If you’re pushing into a tool that takes Slack directly, like a Relativity or Onna, ensure you have the right format to import without issue. Slack exports as JSON, any other format will require additional work to compile by the producing party. At a minimum, make sure your format asks for the following metadata: message ID, channel ID, user ID, timestamp, edits, reactions, pins, hyperlinks, and attachment linkage. Fix the time zone and state deduplication rules that will need to be event or message ID-based.
Threading & completeness. Produce threaded replies with their parents; avoid slices that strip meaning. This goes along with Scope and Context above. Confirm the high-level collection mechanics (Slack Discovery APIs or certified partners) and embed QC steps (spot checks for edits/deletes, reaction preservation, and attachment parity). This step can be very manual to review chats responsive to search terms and ensure you have the right context and all the attachments referenced by hyperlinks.
Retention & holds. If you’re the preserving party, record what was frozen, when, and by whom, including app behaviors and ephemeral settings. Add a change-notice duty if licensing or retention settings change mid-case. If you’re the receiving party, you’ll want to confirm this information if you can get it, but you aren’t necessarily entitled to it under the Rules.
Pilots & iteration. The best way to be sure of the plan is to run a sample production to validate fields and context, plus a timeline for iterative expansion if gaps appear in collected data. Doing it up front reduces cost down the line.
What the case law tells us. Courts favor parties who stipulate form and context early; it prevents midstream re-work and credibility hits. Decisions equate Slack to email for production rigor and repeatedly endorse fixed-window context, but that context needs to provide all responsive messages in a thread or conversation. Courts don’t know the ins and outs of Slack, so it’s up to you to teach the Judge how it works and provide evidence as to why you are not getting what you need on a motion.
Stay tuned for the third and final part of our Slack Tech Tips.
Learn more about Minerva26.
