How to Produce Slack Messages Without Breaking Threads

Listen, here is the thing about Slack and discovery. You can run the export in five minutes, hand over a zip file full of JSON, tell opposing counsel you produced the messages, and none of that means the factfinder can actually read a conversation. I have watched this happen in real matters, the messages are all there technically, every byte accounted for, and the thread is in pieces, scattered across a dozen daily files, each piece looking like an orphaned comment with no parent in sight.

The problem is not the export tool, really. Slack exports exactly what it is designed to export: one message per line, organized by date, one file per channel per day. That is perfectly fine for archiving. It is completely unusable for presenting a conversation to a factfinder, because a conversation is not a list of messages, it is a thread, and a thread in Slack exists only in its interface, held together by a single JSON field called thread_ts that the export tool will walk right past.

This article is about the step everyone skips. Export is step one. Transformation is step two. Step two is where most Slack productions fail - and where this guide begins.

Why Does a Standard Slack Export Break a Conversation?

Slack stores messages in daily JSON files, one folder per channel, one file per day.

Export a channel covering two months and you get roughly sixty files, each containing every message posted that day in timestamp order. That sounds organized, well anyway it is organized the way a filing cabinet is organized when someone dumps everything in by date and calls it done, as of September 2026.

The problem is threads. According to Slack's own developer documentation, once a message has replies it becomes a "parent message," and those replies are "threaded replies" - but that nesting exists only inside Slack's interface. In the raw export, a threaded reply looks exactly like a top-level message unless you read the thread_ts JSON field and know what you're looking at.

Now imagine a thread that started Monday at 11pm and continued Tuesday morning. The parent is in Monday's file. The replies are in Tuesday's file. A reviewer who opens Monday's file sees the initial message. They open Tuesday's file and see what looks like a new, unconnected exchange. The thread is split across two files with no visual indication whatsoever, just a thread_ts value that only an expert would know to trace.

Reddit users who have tried Slack's standard export describe getting "unreadable JSON files, also separated in a confusing manner" - and that is from someone who works with JSON regularly. For litigation purposes, a factfinder who can't follow a thread isn't going to find it less confusing. Courts expect ESI produced in a form that does not obscure the relationship between documents. A thread is a document. Producing its parts as separate entries violates that expectation even if you technically delivered all the bytes.

I have watched review teams spend days manually tracing thread_ts values to reconstruct conversations that should have been produced in threaded form from the start. In one matter the producing party had to supplement after opposing counsel flagged the fragmented output at meet-and-confer. The delay cost time and credibility both.

An export is not a production. Between export and production sits the transformation step, and that step is where most Slack discovery fails.

What Does Slack's Raw JSON Actually Contain?

Before you can fix a Slack production, you need to understand what the export contains. A standard Slack workspace export is a zip archive. Inside that zip:

• channels.json: every public channel with its ID, name, creation date, and topic
• users.json: every workspace member with their user ID, display name, real name, and email address
• One folder per channel, named by the channel handle (for example, general or project-alpha)
• Inside each channel folder, one JSON file per day, named by date (for example, 2024-10-14.json)

Slack's documentation defines the thread terminology precisely: a message with no replies is an "unthreaded message"; once it has replies it becomes a "parent message"; replies are "threaded replies." Each message object in a daily file contains the fields that matter for discovery:

Two things are absent from a standard export that are critical for complete discovery. First, private channel messages and direct messages are not included. Standard exports cover public channels only. For private channels and DMs, you need Slack's Discovery API (Enterprise Grid required) or a third-party compliance integration.

Second, file attachments are not bundled in the zip. The export contains metadata and download URLs, but the actual files must be separately downloaded before those URLs expire. In a large production, leaving file download to the last step forces a supplemental production you could have avoided.

Understanding this structure is the prerequisite for everything that follows. You cannot group threads correctly without knowing how thread_ts works. The data is all there; it just isn't in any form a factfinder can read without transformation.

How Do You Run a Complete Slack Export?

The export method you use determines what data you get. Choosing the wrong one leaves gaps that opposing counsel will find.

An AmLaw 50 firm handling a high-stakes antitrust matter processed Slack alongside Google Workspace and cloud archives, noting that Slack data "arrives in unstructured formats requiring normalization before review" - the export step is only the beginning.

For most litigation matters, the Discovery API is the right tool. A typical workplace dispute, harassment claim, or contract case is at least as likely to involve DMs as channel messages. People have sensitive conversations in direct messages on purpose. If your export covers only public channels, you have a material gap before you begin processing.

Standard export steps (Workspace Owner required):

1. Go to your-workspace.slack.com/admin and select Import/Export Data
2. Choose Export, set a date range, and click Start Export
3. Wait for an email notification (may take several hours for large workspaces), then download the zip file
4. Verify the zip contains the expected channel folders before proceeding to transformation

Discovery API steps (Organization Owner required, Enterprise Grid):

1. Create a Discovery app in the Slack API dashboard with the discovery:read scope
2. Use discovery.enterprise.info to enumerate users and channels
3. Use discovery.conversations.history to pull messages per channel per custodian
4. Paginate through results using the cursor parameter until all messages are retrieved

One thing people consistently miss: Slack deletes messages older than the workspace's retention policy, and the export only gives you what is currently in the system. If your client has a 90-day retention setting and the litigation hold wasn't issued until day 95, the first five days are gone. Issue litigation holds immediately on notice of potential litigation and confirm retention settings at the outset. This conversation has to happen before any export runs.

How Do You Rebuild Threaded Conversations from Raw JSON?

Here is the process I use to transform flat Slack JSON into production-ready conversation units.

It is methodical, it is defensible, and it produces output that a factfinder can actually read. The community technical record confirms this is not a solved problem out of the box: developers report that even with the chat.postMessage API, "capturing and storing thread_ts" is the linchpin step for preserving any thread - meaning you have to know to look for it and what to do with it.

Step 1: Parse all daily files into a single message list. Load every JSON file across every channel directory into one data structure. Tag each message with its channel name and original file path for provenance. Do not skip bot messages or system messages without a documented decision - they are part of the record.

Step 2: Resolve user IDs to real names. Every user field and every mention in the text field contains a Slack user ID, not a name. Cross-reference users.json to substitute the real name and email. For in-text mentions, resolve patterns like <@U04B7XKRM> to @Jane Smith. A production that delivers opaque user IDs is not usable.

Step 3: Convert timestamps. The ts field is Unix epoch with microsecond precision. Convert to a human-readable format in the custodian's local timezone with UTC offset: 2024-10-14 11:23:45 EDT (UTC-4). A message sent at 11pm Eastern is the next calendar day in Pacific time, and that can shift a timeline argument.

Step 4: Group messages into conversation units. This is the key step. The rule: if a message's thread_ts equals another message's ts, they belong to the same conversation unit. The message whose ts matches is the parent. All messages sharing that thread_ts are replies. Within each unit, sort by ts ascending. Between units, sort by the parent's ts. The result is a channel view organized thread by thread, every reply under its parent, in send order.

Step 5: Handle orphaned replies. A small percentage of messages will have a thread_ts that does not match any parent in the export - because the parent was deleted, falls outside the export date range, or a workspace quirk. Do not silently drop these. Flag them in your processing log. Their unexplained absence from a production is a challenge waiting to happen.

What Does a Defensible Slack Production Look Like?

A defensible Slack production has three properties: it is complete, it is readable, and it is auditable.

You can produce a technically complete export that fails on the other two, and you will hear about it at meet-and-confer.

Completeness means you captured all custodians in the litigation hold, all channels those custodians participated in during the relevant period, and all DMs and group DMs between custodians. It also means file attachments were separately downloaded and produced with load files that link each attachment to its parent message. In enterprise-scale matters, one AmLaw 50 firm's eDiscovery platform normalized "Slack, Teams, and Google Chat messages into time-ordered transcripts with participants, timestamps, attachments, and even emojis or reactions, ensuring accurate context." That is the benchmark. A production that omits DMs because the standard export was used instead of the Discovery API is incomplete by definition.

Readability means the production is organized so a reviewer can follow a conversation without special software. I recommend one of two formats:

• PDF or rendered HTML per conversation unit, formatted as a chat transcript: timestamp, sender name, message text, attachment references. Replies are visually indented or labeled "Reply to [parent timestamp]." This is the most reviewer-friendly format and it renders well in Relativity, Nuix, and Logikcull.
• Delimited text or CSV with structured columns: Channel, Thread_ID, Parent_Message_ID, Timestamp, Sender_Name, Sender_Email, Message_Text, Attachment_Count. Suitable for loading into any review platform with proper field mapping.

Whichever format you choose, the thread relationship must be structurally apparent to anyone who opens the file. A flat, chronologically sorted CSV with no thread grouping is not a defensible production even if it contains all the data.

Auditability means you can explain exactly how you produced the data if challenged. At Relevant Discovery, our processing pipeline maintains immutable originals with content hashing, append-only audit trails, and a documented chain of custody for every collection. Keep a processing log: the export date, plan and export method used, date range, channels and custodians included, message count before and after processing, orphaned replies flagged, and the script used for transformation.

Before finalizing any production, run a spot check. Take three conversation units at random from the final output, look them up in the live workspace, and verify all replies are present and in order. A 30-minute spot check has caught processing errors more than once. Catching them before production is vastly better than catching them in a motion to compel.

How Do You Apply Proportionality to a Large Slack Collection?

A busy Slack workspace generates between 500,000 and 2 million messages per year per 100 active users.

That is not a document count. It is a fragment count if you don't thread it, and a much smaller conversation-unit count if you do. Threading transformation typically reduces the apparent document count by 40 to 60 percent by grouping messages into conversation units. Proportionality under Rule 26(b)(1) requires thinking before you export, not after the zip file arrives.

Start with custodians, not channels. Most cases have a defined set of key people. Identify their Slack user IDs first. Then identify every channel those custodians participated in during the relevant period. That is your collection scope. Pulling all 300 channels in a workspace when only 14 involve your custodians is not proportionate, and any competent opposing counsel will say so. For broader context on how over-collection creates challenges, see 7 Ways Opposing Counsel Attacks an ESI Collection.

Apply date-range narrowing before export. Slack's Discovery API lets you filter by date. Use it. A two-year export for a dispute that arose in the last quarter of year two is over-collection. Start with the three months immediately before and after the triggering event. Expand if meet-and-confer requires it, but start narrow and document your reasoning.

Use keyword screening before full conversion. After export but before the threading transformation, run keyword searches against the raw JSON message text. Identify conversation units containing at least one keyword hit, then process only those units to final production format. Non-hit messages should be documented as collected but not produced, with a count in the processing log.

The Slack proportionality conversation belongs at the Rule 26(f) conference, not after the export is already running. If opposing counsel demands a full workspace export with no custodian or date scoping, that is a meet-and-confer argument, not a production task. Document the scope you proposed and the reasoning, and let the record speak.

Python: Reconstructing Threads from a Slack Export

import json
from pathlib import Path
from datetime import datetime
from zoneinfo import ZoneInfo

def load_users(export_dir):
    with open(Path(export_dir) / "users.json") as f:
        users = json.load(f)
    return {
        u["id"]: {
            "name": u.get("real_name") or u.get("name", u["id"]),
            "email": u.get("profile", {}).get("email", "")
        }
        for u in users
    }

def convert_ts(ts, tz="America/New_York"):
    dt = datetime.fromtimestamp(float(ts), tz=ZoneInfo(tz))
    return dt.strftime("%Y-%m-%d %H:%M:%S %Z (UTC%z)")

def parse_channel(channel_dir, users, channel_name):
    messages = []
    for json_file in sorted(Path(channel_dir).glob("*.json")):
        with open(json_file) as f:
            for msg in json.load(f):
                if msg.get("type") != "message":
                    continue
                uid = msg.get("user", "UNKNOWN")
                messages.append({
                    "ts": msg["ts"],
                    "thread_ts": msg.get("thread_ts"),
                    "user_name": users.get(uid, {}).get("name", uid),
                    "text": msg.get("text", ""),
                    "reply_count": msg.get("reply_count", 0),
                    "timestamp_human": convert_ts(msg["ts"]),
                    "channel": channel_name,
                    "source_file": str(json_file),
                })
    return messages

def group_into_threads(messages):
    """
    Rule: if message.thread_ts == parent.ts, same conversation unit.
    Orphaned replies (no matching parent) are flagged, never dropped.
    """
    parents = {}
    orphaned = []
    for msg in messages:
        ts, thread_ts = msg["ts"], msg.get("thread_ts")
        if thread_ts is None or thread_ts == ts:
            parents.setdefault(ts, {"parent": msg, "replies": []})
        elif thread_ts in parents:
            parents[thread_ts]["replies"].append(msg)
        else:
            orphaned.append(msg)

    if orphaned:
        print(f"WARNING: {len(orphaned)} orphaned replies - "
              "parent outside date range or deleted. Logged; not dropped.")

    for unit in parents.values():
        unit["replies"].sort(key=lambda m: float(m["ts"]))

    return sorted(parents.values(), key=lambda t: float(t["parent"]["ts"]))

What Will Matter Most for Slack Discovery in the Next 12 to 24 Months

Three trends are converging on Slack collections right now, and in my view they will make thread reconstruction less optional and more contested within the next two years.

AI-generated Slack activity will complicate custodian scope

Enterprise Slack workspaces now include bot-generated messages, AI summaries, workflow automations, and integrated tool notifications alongside human conversation. The question of whether AI-generated Slack content is ESI subject to preservation is unsettled, and courts will be asked to answer it. For practical purposes, I would recommend identifying and separating bot messages from human messages during the transformation step today, so you are not reclassifying them under court order later.

Slack's retention defaults are shortening

Under pressure from data minimization requirements in privacy regulations, more organizations are configuring 90-day or 180-day Slack retention policies. That means the litigation hold timing problem I described earlier is getting worse: the window between when a dispute arises and when relevant messages are deleted is narrowing. Expect more Rule 37(e) sanctions motions centered on Slack data as these shorter retention windows catch counsel by surprise.

Courts will begin demanding threading, not just export

The first wave of Slack discovery disputes focused on whether messages were produced at all. The next wave is about whether they were produced in a readable form. I expect within 24 months to see courts issuing explicit orders about Slack production format, the same way courts have addressed email threading and native file production in prior cycles. Establishing your threading methodology now, before you are arguing about it, is the conservative position.

In summary: the teams that build a repeatable Slack processing pipeline today will not be scrambling to defend their methodology in court tomorrow.

The work of producing Slack messages without breaking threads is not glamorous. It is a pipeline: five transformation steps, a spot check, a processing log. But it is the work. A factfinder who reads a flat list of chat messages is not going to understand what the parties discussed, when they agreed, or who said what in a thread that ran from Monday night to Thursday morning. The conversation is the evidence. Threading is how you preserve it.

I have watched productions fail the simplest test: could a factfinder follow the conversation without calling counsel to explain it? The answer was no, and the cost was supplemental production, delayed schedules, and credibility in front of a judge who had already noticed. The producing party had technically delivered all the data. They just hadn't produced it in a form anyone could use.

Export the workspace with the right tool. Transform the JSON into threaded, timestamped, user-resolved conversation units. Document every step in a processing log. Run the spot check. That is defensible Slack discovery. Everything else is just delivering bytes and hoping no one looks too closely.

If Slack processing is part of a larger collection effort, see how we approach the full pipeline in The Processing Exceptions Your Vendor Isn't Showing You - the gaps that don't appear in the production report are usually the ones opposing counsel finds first.