Collecting chat: Slack, Teams and why messaging breaks the old workflow
Chat evidence does not arrive as documents: preservation, unit selection, rendering, and protocol design determine whether Slack or Teams data can be reviewed and produced reliably.
Collecting Slack and Teams evidence requires defining the reviewable unit, preserving chat beyond ordinary retention settings, and capturing messages, metadata, attachments, and workspace relationships. These decisions should be settled at the Rule 26(f) conference before collection begins because chat does not fit the conventional document workflow.
- A reviewable chat unit can be an individual message, a day’s transcript, a defined thread, or an entire channel.
- External participants may limit the organization’s control over complete channel history and account data.
- A load file can provide structured processing data, but the source export and field definitions should be retained.
- Structured chat formats depend on supplied fields, load-file consistency, and whether recipients can reproduce relationships reliably.
Collecting chat: Slack, Teams and why messaging breaks the old workflow
Slack, Teams, and other collaboration platforms turn legal evidence into conversations rather than discrete files. That distinction affects every stage of discovery. A message may be edited, deleted, moved, reacted to, attached to a thread, or stored in a workspace shared with people outside the organization. The conventional workflow—identify custodians, collect files, process them, review each document, and produce a document family—cannot simply be applied without deciding how chat should behave.
The resulting query is underserved because the technology is familiar but the discovery mechanics are not. In-house counsel may know where a conversation occurred without knowing what should be collected, how it should be preserved, or what a reviewing attorney should see. Litigation support may understand search and analytics while still treating every message as an isolated document. A practice-group lead may receive a preservation request and need to determine which platform administrators, custodians, and outside participants can affect the result.
Chat does not fit a document-shaped process#
There is no document in the ordinary sense. A conversation is a continuous stream of messages generated across channels, direct messages, threads, shared workspaces, and external participants. Each unit can contain context that an email does not: an answer several messages later, a reaction that changes meaning, a file posted before the discussion, or a link to content stored in another system.
Someone must therefore decide what constitutes the reviewable unit. A practical unit might be an individual message, a day’s transcript, a defined thread, or an entire channel. Each choice changes more than presentation. It affects the number of items presented for review, the context available to the reviewer, the burden of redaction and privilege analysis, the structure of family relationships, and the practical shape of the production.
Per-message review can preserve granularity but may break a conversation into fragments. A daily transcript keeps adjacent messages together but can become difficult to navigate and may obscure the relationship between a message and its thread. Thread-based review captures a narrower sequence while potentially splitting a discussion that continued in another channel. Channel-level review may provide context but can combine unrelated business and legal topics.
The point is not that one unit is always superior. The point is that unit selection is a discovery decision, not a formatting preference. It belongs in the conferral record, review protocol, and production specification rather than being left to a platform export or a vendor default.
Map the evidence before selecting a collection method#
A useful first step is an evidence map that distinguishes the data sources likely to matter. Direct messages may contain discussions that never appeared in a channel. Channel messages may identify participants or decisions reflected elsewhere. Threads may pull selected replies out of the surrounding stream. Reactions and edits can indicate chronology or changes in meaning. Shared files may exist in chat while their authoritative content lives in a file repository, document-management system, or another service.
Each source creates a different preservation and collection question. For direct messages, the issue may be conversation membership rather than channel selection. For threads, the collection may need to include parent and reply messages. For reactions, the collection may need to preserve both the reaction and its associated message. For shared files, the filename or link alone may not capture the file, its versions, or the content available at a different point in time.
Links deserve particular attention. A message linking to a file stored elsewhere does not necessarily contain the linked content. The link may preserve the existence and wording of a reference, while the linked document remains subject to separate collection, processing, and review. That division can create two production components: chat messages with embedded references and the external files to which they point.
External and shared workspaces complicate attribution. A conversation may include participants from another organization, a customer, a contractor, or a shared channel. The organization may control some messages but not the complete channel history or the accounts of external participants. The evidence map should record who administers the workspace, who can export it, which content is visible, and whether material outside the organization’s control requires a separate preservation request or agreement.
Preservation must override the retention setting#
Chat retention is usually configured by an administrator for business reasons rather than legal ones. Retention settings may shorten the life of message content, revisions, files, or audit information. A legal hold therefore has to interact with platform configuration; simply identifying custodians and sending a hold notice does not establish that material will remain available for collection.
This is a recurring preservation failure in modern matters. If a message disappears after the duty to preserve arose, the later explanation that the platform’s ordinary setting removed it does not resolve whether the loss can be addressed under Rule 37(e). That rule’s consequence depends on the court’s findings, including any prejudice and, for the more severe tier, intent to deprive. The protocol should therefore distinguish preservation from collection: preservation addresses continuing availability, while collection captures the material that can still be retrieved.
Preservation discussions should identify the platform owner, relevant workspaces and channels, direct-message and thread scope, external participants, attachments, editable content, and linked systems. They should also address whether preservation is performed through a platform feature, by suspending an administrative setting, by targeted collection, or through some combination. Where available, preservation should capture enough metadata to establish when action was taken and what was in scope.
Edits and deletions make the audit trail important. A preserved export may need to include information about changes rather than only the final message text. The requested scope should be stated in terms the administrator can implement. A request for “all messages” is ambiguous when the platform stores replies, reactions, thread relationships, attachments, and revisions in different structures.
Collection requires more than a transcript export#
Chat collections often combine several data types. Message text provides the conversation. Metadata establishes authorship, timing, channel membership, thread relationships, edits, and deletion events where retained. Attachments and links connect the conversation to other content. Custodian and workspace information connects the data to the people and places from which it originated.
The collection method should preserve those relationships. Exporting only visible message text may omit the context needed to distinguish a new message from an edited message or to determine which replies belong together. It may also separate a shared file from the message that introduced it. A load file can provide structured data for processing, but the source export and its field definitions should be retained so that later normalization remains auditable.
Processing should identify the relevant collection universe before review begins. Email threading, de-duplication, near-duplicate detection, and attachment analysis are familiar tools, but chat requires careful treatment of boundaries that are not always conventional documents. The processing specification should document how messages are grouped, how duplicate messages are treated, how threads are represented, and how attachment references are linked back to the conversation.
The EDRM provides a useful organizing concept, but collection is not the beginning of every matter. EDRM begins with information governance and includes identification, preservation, collection, processing, review, analysis, production, and presentation. It is a reference model rather than a mandatory sequence, and chat matters commonly loop between stages. A disputed review unit may send the team back to collection; a missing attachment may send it into another repository; a production problem may require renewed privilege analysis.
Search and review depend on the unit and the protocol#
Keyword search and technology-assisted review can both support chat review, but the choice should reflect the record and the parties’ agreement. In Da Silva Moore v. Publicis Groupe, the court accepted computer-assisted review as an acceptable search method in an appropriate case, and the parties’ agreement was important. In Rio Tinto PLC v. Vale S.A., Judge Peck described judicial willingness to permit technology-assisted review as black-letter law and later appointed a special master to resolve disputes concerning its use.
Chat does not eliminate those questions; it adds conversational context to them. A reviewer may need to assess a message together with the messages that answer it, while the review model classifies the unit presented. If the protocol defines the unit as a single message, the workflow should state whether surrounding messages are supplied as context and whether those contextual messages are separately reviewed. If the unit is a daily transcript or thread, classification and context operate differently.
Boolean or keyword search remains a familiar option, while CAL and other forms of TAR may be considered where the collection and review design support them. Predictive coding is commonly discussed in that context, but the practical record should address the data population, the unit, the training process, validation, quality control, and treatment of privileged or withheld material. The relevant disagreement is often not whether software can assist review, but whether its output has been configured for the conversational material actually under review.
Hyles v. City of New York likewise reflects a court’s reluctance to require a producing party to use TAR when it prefers keyword searching. That is consistent with Sedona Principle 6, under which the responding party is best situated to decide how to search for and produce its own ESI. Some language in Rio Tinto and Hyles is dicta rather than holding, so those decisions signal judicial attitude rather than establish a binding rule.
Production format determines usability#
Chat can be rendered as individual messages, daily transcripts, thread-based productions, or an RSMF-style structured format. No format solves every problem. Per-message productions preserve granularity but can make a conversation difficult to read. Transcripts improve continuity but may require pagination, navigation features, or agreed handling of attachments. Structured formats can preserve metadata and relationships, but their usefulness depends on the fields supplied, the consistency of the load file, and whether recipients can reproduce the relationships reliably.
The parties should negotiate the format before review begins. The review unit, the production unit, and the unit displayed to the receiving party need not be identical, but their relationship should be explicit. Otherwise reviewers may structure work around one unit and later incur additional effort to translate it into another. Redactions and privilege decisions also need an agreed treatment when a message is withheld within a transcript or thread.
Rule 34(b)(2)(B) requires a responding party to state the grounds for an objection with specificity. Rule 34(b)(2)(C) requires the objection to state whether responsive material is withheld on that basis. Those provisions do not settle the appropriate chat production format, but they make the factual record for any objection important. The protocol should distinguish an objection to the scope or form of a request from an objection to particular message content.
Clawback treatment should also be addressed. Federal Rule of Evidence 502(d) permits a federal court to order that privilege or work-product protection is not waived by disclosure in the proceeding before it. For chat, the mechanics matter: a message may be part of a thread, a daily transcript, or a structured family. The production and clawback procedures should explain how a disputed item is marked, logged, segregated, and replaced without losing its relationship to the conversation.
Late agreement is costly because collection, processing, review, redaction, loading, and quality control may already reflect incompatible assumptions. Changing the unit late can require reconsideration of what was reviewed and how errors or exceptions were identified. It can also complicate privilege logging and add another stage of validation before production.
Settle the protocol at the Rule 26(f) conference#
Rule 26(f) requires the parties to confer before the scheduling conference, and Rule 16(b) governs the scheduling order. The chat-specific protocol should supplement those discussions before collection begins. It does not need to resolve every technical possibility, but it should prevent assumptions about scope and format from surviving until review is substantially complete.
At minimum, the conferral record can address the collection universe, the unit of preservation, the review unit, the production format, treatment of threads and reactions, handling of edits and deletions, the role of attachments and external links, external-workspace access, and the process for testing completeness. It should also record how privilege, work product, confidentiality, and personal information will be handled; how withheld material will be logged; and what quality-control checks will support the production.
Scope should reflect the proportionality factors now contained in Rule 26(b)(1), including the parties’ relative access to relevant information. That factor is particularly relevant when chat spans internal custodians, external participants, shared workspaces, and linked repositories. The record should show which sources are reasonably accessible, where access differs, and how the proposed search and collection approach accounts for that difference.
The most durable chat strategy is not a single export method. It is an explicit chain of decisions connecting preservation, collection, processing, review, and production. That chain allows a team to explain not only what was produced, but why each conversation appeared in the chosen unit, how context and related files were handled, and what happened when a retention setting, edit, deletion, or external workspace affected the record.
Common questions#
What can serve as the reviewable unit in chat discovery?
A practical unit might be an individual message, a day’s transcript, a defined thread, or an entire channel. Each choice affects context, review volume, redaction, privilege analysis, family relationships, and production.
Why must preservation override ordinary retention settings?
Retention settings may shorten the life of message content, revisions, files, or audit information. Identifying custodians and sending a hold notice does not establish that material will remain available for collection.
What does a chat collection need beyond visible message text?
Metadata establishes authorship, timing, channel membership, thread relationships, edits, and deletion events where retained. Attachments, links, and custodian and workspace information connect the conversation to related content and its origins.
When should parties settle the chat-specific discovery protocol?
Rule 26(f) requires the parties to confer before the scheduling conference. The chat-specific protocol should supplement those discussions before collection begins.
Intraspexion is an independent research publication about eDiscovery and legal technology. It is not affiliated with, endorsed by, or a successor to the former Intraspexion, Inc., and makes no claim to that company’s patents or products. Nothing here is legal advice; vendor names and trademarks belong to their respective owners.
More in Platforms
All 7 guidesDISCO eDiscovery: the per-document model explained
DISCO’s pricing page references a per-document pricing unit but publishes no price figure.
Everlaw pricing: what is published, what is not, and what moves the number
Everlaw publishes no pricing figure or pricing unit; its pricing page routes buyers to a scheduled meeting, leaving scope, volume, hosting and services to…
Microsoft Purview eDiscovery: what it covers and where it stops
Microsoft Purview eDiscovery identifies, preserves, and exports tenant content for external review, but licensing, metadata, scale, and governance require careful planning.
Logikcull pricing: the per-GB model and what it suits
Logikcull’s November 2026 pricing page names per-GB and per-month units without publishing figures, making volume, retention and trial design the key evaluation questions.