Companies that delete slack messages automatically shoot themselves in the foot. Whatever legal exposure you reduce is vastly outweighed by the convenience factor.

Believe it or not, some companies out there simply won't pay for Slack and will just use the free tier, which will eat the messages after some time anyways.

Of course, if billing or other concerns prevent them from doing this, i fail to see why they don't just use self hosted solutions, like Rocket.Chat, which isn't all that hard to do either.

I actually did that myself and wrote about it on my blog: https://blog.kronis.dev/tutorials/lets-run-our-own-chat-plat...

>i fail to see why they don't just use self hosted solutions, like Rocket.Chat, which isn't all that hard to do either.

I would assume CYA. If a self-hosted, non-industry-standard program went down, the person who set it up would be putting be their balls on the line. If Slack goes down, they can blame someone externally.

The companies might night be deleting slack messages automatically. They might just be on the free plan which only shows the most recent 10,000 messages.

A company that's a going concern has money to pay for Slack. We have maximum data retention requirements of a legal nature, so we are deleting Slack messages with fully conscious intention.

So many times I've searched some weird intranet hostname, or $megacorp_specific_lingo and found it in Slack, yet nowhere in our Confluence. Confluence is great for more long-form stuff, but it also gets stale. But the great thing with a slack message, it's mostly immutable, so I can see the date (a decent proxy for relevance). I don't have to peer through the edit history in Confluence to ascertain the age of the information on a document with a long lifespan and many edits.

I was a part of company during a Hipchat > Teams migration that saw us lose all direct message history. The amount of knowledge lost was incalculable. It was certainly a wakeup call for me to start documenting stuff more permanently.