Since the beginning of the COVID-19 pandemic, hundreds of millions of people shifted to working from home, leading to soaring demand for workplace communication tools over the past year. As the pioneer in the nascent field of cloud-based workplace communication, Slack spearheaded the growth from the disruptions caused by the coronavirus, nearly doubling the number of new customers in the fiscal year 2020 compared with the prior one.
Slack is designed to replace the overuse of email within an organization. Rather than the traditional inboxes, Slack communications are organized into channels and private messages, corresponding with various projects and user groups. Users perceive this structure as much more flexible and less “corporate” compared to email or other messaging applications. Within a given channel, users may converse and share files. For example, a marketing team may create a discrete channel for a pending ad campaign, in which team members can brainstorm and share relevant digital materials to collaborate on a solution. Under this system, the conversations and files are stored in a single channel, rather than being stored separately in each user’s email inboxes. The platform manager or channel creators may then decide how long they wish to preserve data in certain channels or when certain channels should be deactivated.
Yet while Slack’s functionalities become increasingly robust, its data has also become increasingly complex. In a single channel, one may find messages, documents, threads, edits, deletions, and so much more. This presents a nightmare for legal teams trying to sift through the messages to find relevant information from an eDiscovery standpoint. Before Slack developed specific APIs for eDiscovery, the process for obtaining Slack data was less transparent and more akin to a “black box,” leading to technical and workflow challenges in the discovery process and resulting in production delays and high costs. The extreme amount of electronically stored information (ESI) exported from a Slack channel, in its original comprehensive JSON format, is difficult to decipher even for a process engine. Moreover, JSON files also make identifying relevant information very difficult, leading to costly and unnecessary processing via human labor.
Recent case law had limited opportunities to illustrate this difficulty revolving companies’ discovery obligations, and courts have split opinions regarding whether Slack data can be subject to compelled production.
In Milbeck v. TrueCar Inc., the U.S. District Court for the Central District of California refused to compel production of Slack data, holding that review and production of Slack data would be “unduly burdensome,” even though Slack data contained information that was "at the heart of this case".
In Calendar Research LLC v. StubHub Inc., however, the same court compelled the defendants to supplement their initial production once the Slack account was upgraded, thus allowing additional messages to become available for production. Importantly, the defendants did not raise burden arguments, and it is debatable whether the court would have held the same had a similar argument as in Milbeck had been made.
And in West Publishing Corp. v. LegalEase Solutions LLC, the U.S. District Court for the District of Minnesota affirmatively compelled production of Slack data, but required the party seeking discovery to share the processing and production costs.
Nevertheless, as more advanced eDiscovery tools and techniques become available for the management, preservation, and production of Slack data, and as the use of Slack becomes more widespread within organizations, it is inevitable that companies will be increasingly less able to withhold such data from discovery in all circumstances. Several options already exist. First, Slack has built-in, customizable retention settings for messages and files, and the default setting will retain everything to prevent data loss. The preserved data can now be collected using one of Slack’s Discovery APIs. In particular, eDiscovery apps can pull messages and files from Slack, and store the information in third-party data warehouses, from which the messages and files can be searched, archived, or retrieved.  Slack’s Audit Logs API on the other hand, is geared to detect suspicious activity and spot security issues. As such, it is more tailored for smaller-scale, internal investigations.  Outside of Slack’s self-developed APIs, eDiscovery vendors like such as Onna are also available to capture and process the data in a simple, cost-effective way.
Due to the availability of these tools, companies should thus be prepared that they may be compelled to review and produce Slack data if they become subject to litigation or investigation. They should take proactive steps to ensure that such data is preserved and can be collected, reviewed and produced in a manner that satisfies their legal obligations, while avoiding overpreservation, overdisclosure, and overproducing irrelevant, sensitive or privileged information. In light of the courts’ limited opportunities to discuss discovery obligations with respect to Slack data, companies also should stay vigilant of legal developments in this area.
- Companies should carefully limit channels only to necessary participants, otherwise a company may be obligated to preserve and review data from all channels in which that user participated.
- Companies should take special care to limit third-party access to company channels, otherwise privileged conversations in select channels may be waived. Companies should audit channels, both for the substance of conversations and for user access. They should promptly remove users from channels in which their participation is unnecessary, and new channels should be created for conversation topics that appear not to belong in the channel in which they are taking place. 
- Channels should be descriptively titled, and employees should be reminded to limit conversations within channels to the relevant topic, so that it may allow companies to negotiate with opposing counsel or regulators to review only channels with facially relevant titles. 
- Companies should put these protocols in writing and ensure that users familiarize themselves with the protocols. Periodic brief training sessions to reinforce the protocols are advisable as well. These efforts will support companies' assertions during discovery negotiations that only facially responsive, nonprivileged channels should be collected and reviewed.