Every organisation that works in Slack still has email arriving somewhere else. Vendor notifications, form submissions, the address a partner replies to. The work is in one place and a meaningful slice of the information about it is in another, which someone checks when they remember. The obvious fix is forwarding. Point the mailbox at a Slack channel and let the integration post everything. It takes an afternoon, and it fails in a way that is worth describing precisely, because the failure is not "it did not work". It is that it worked exactly as specified and made things worse. What forwarding actually produces Truncated bodies. The integration posts a preview. The part of the email that says what to do is below the fold, so every message becomes a link to the thing you actually needed, and the channel is a table of contents for an inbox people are still opening. Reply chains, repeatedly. A thread with six replies does not arrive as one conversation. It arrives as six posts, each quoting all the previous ones, so the channel fills with the same text at increasing lengths. Auto-replies. Out-of-office, delivery receipts, no-reply confirmations. None of it is work and all of it arrives with the same weight as the message from a partner asking a real question. The predictable outcome is that the channel gets muted, and now the information is in two places neither of which anyone is reading. Routing, not forwarding The distinction that makes this work: a router decides what belongs in Slack and in what shape, rather than moving everything and hoping the reader filters. Concretely that means four things the forwarding integration does not do. Deduplication on the RFC Message-ID. Every email carries a globally unique Message-ID header, and replies carry In-Reply-To and References pointing back at what they answer. That is the correct identity for a message, rather than a hash of subject and sender, which collides on exactly the automated mail you receive most. The router keeps a seven-day lookback of what it has already posted, which is long enough to cover a thread going quiet over a weekend and short enough that the state stays small. Thread and reply detection. Because the headers say what answers what, a reply can be posted into the Slack thread of the message it answers instead of starting a new one. The conversation in Slack has the shape of the conversation in the mailbox, which is the whole point and is the thing forwarding cannot do. Body extraction rather than preview. Multipart MIME, quoted history, signature blocks and tracking pixels are all separable from the sentence somebody actually wrote. Extracting that means the Slack message is the message, and nobody has to open the mail client to find out what was being asked. Noise suppression. Auto-replies and no-reply senders are identifiable before posting, not after. They are dropped rather than muted, because a muted channel is a solved problem that will unsolve itself the moment the mute is lifted. The detail that decides whether people trust it The router processes in controlled batches and preserves unread state. That sounds like an implementation footnote and it is the reason the system is used. If reading the mailbox programmatically marks messages read, the router has silently taken over as the only reader, and the person who owns that inbox has lost the ability to work it directly. They will not say this explicitly. They will just stop relying on it, because something is now touching their mail in a way they did not ask for and cannot see. An automation that changes state it was not asked to change is not a convenience. Leaving the mailbox exactly as it found it is what makes the router additive rather than a takeover, and it is the difference between a tool people keep and a tool people quietly route around. Where it sits now Operational email is owned in Slack, where the team already works, rather than in a side inbox somebody checks. Threads look like threads. Auto-replies do not arrive. The mailbox still works normally for anyone who wants to open it. The general principle, which applies well beyond email: moving information between systems is easy, and almost never the problem. The problem is that the receiving system has a shape, and information that arrives in the wrong shape is worse than information that did not arrive, because it costs attention before it can be ignored.