Can You Download A Slack Conversation ((TOP))
Perry Barillari
In the new model, just use conversations to access anything channel-like. For example, the conversation.list method returns information on public, private, and direct message channels, when accessed with the appropriate permission scopes.
Some of the most important fields in conversation objects are the booleans indicating what kind of conversation/channel it is and how private it is. For a list of these booleans, refer to conversation-related booleans.
All Conversations API endpoints still accept multiple scopes and filter access to channels based on the provided token's scope. If you have a scope that allowed you to use a deprecated conversation method, that scope will work with the Conversations API equivalent.
Just set a limit on your first request, include the next_cursor found in response_metadata in the response as the cursor parameter in your next request and you're paginating with ease on the conversational trapeze. Unlike older methods, the Conversations API is paginated by default.
When looking up MPIMs using the conversations.list, you are likely to get far fewer results than requested number with a next_cursor value, although next_cursor will continue to indicate when more results await. For example, when requesting 100 MPIMs, it may return only 5.
There are a few circumstances where channel IDs might change within a workspace. You can use conversations.list regularly to monitor change for known #channel names if ID stability is important to you.
Information about required scopes
This Conversations API method's required scopes depend on the type of channel-like object you're working with. To use the method, you'll need at least one of the channels:, groups:, im: or mpim: scopes corresponding to the conversation type you're working with.
A conversation object contains information about a channel-like thing in Slack. It might be a public channel, a private channel, a direct message, a multi-person direct message, or a huddle. You'll find all of these objects throughout the Conversations API.
As long as the authenticated user is a member of the private channel, pass the channel's ID (C123456) to the channel parameter and the message will be posted to that channel. The private channel's ID can be retrieved through the conversations.list API method.
As long as the authenticated user is a member of the multi-person direct message (AKA "private group" or MPIM), you can pass the group's ID (G123456), and the message will be posted to that group. The private group's ID can be retrieved through the conversations.list API method.
If you want your app's bot user to start a 1:1 conversation with another user in a workspace, provide the user's user ID as the channel value and a direct message conversation will be opened, if it hasn't already. Resultant messages and associated direct message objects will have a direct message ID you can use from that point forward, if you'd rather.
Bot users cannot post to a direct message conversation between two users using chat.postMessage. If your app was involved in the conversation, then it would be a multi-person direct message instead. Apps can post to direct message conversations between users when a shortcut or slash command belonging to that app is used in the conversation.
A colleague has announced they are leaving the company in 2 weeks. A few weeks ago, another colleague left the company, and his Slack account immediately disappeared, and I could no longer see any of the old conversations I had with him.
I have already tried going into the Slack client, and scrolling all the way up to the beginning of my conversation history with my colleague. Then I pressed CTRL-A to select everything, and copied and pasted it into a document. What happened is that only the first few months of conversation history were pasted into the document, so that means while you are scrolling through the conversation history, Slack only keeps a few months of history in the buffer.
Most development efforts change hands over time. We may work on thisproject today, but next month some of us will probably move on to otherprojects and new people will arrive. These new developers ask questionsabout why something was done and there are one of two answers, depending onwhether the conversation was on Slack or GitHub:
Today I had a frustrating conversation with a colleague from another team that went back and forth. Nothing very serious, but just disagreements.After the conversation was over I just needed to talk about it with my direct manager and since my day 1 in the company he has been adamant that I should trust him and I should not accumulate frustrations to myself and he's there to alleviate the problems for me.
We didn't go on a video call as I wanted to avoid wasting more time on the matter and explaining the entire thing to him. So I just sent the screenshot of my conversation with this other colleague to him so he could judge and understand what I was talking about.
Now, a few hours later somehow I'm wondering if that was a good idea and if it's even ethical/professional to do so. Obviously the conversation was just about work matters and there was nothing personal or compromising for the other colleague, but I just have this feeling that if I was in the colleagues place and someone approached me and say "so, Bob showed me what you guys discussion about " I'd probably feel weird about it and decide that the person is not to be trusted and I have to be careful what I write to him and it would make me feel bad.
A professional conversation on some IM tool is not different from an email. There is no expectation of privacy for the most part. With an email, it would be perfectly normal to just forward it to your manager in case of disagreements, especially with an external team. With the IM, it is not as easy but for me it is the same. Of course, some people would feel a little bit annoyed (or worse) if you reported them to your manager for some reason. But the way to do so (forwarding email, screenshot) is not really that different. Needless to say that there is also CCO, which serves the very same purpose.
To sum it up, I do not think it is a bad thing to do per se, but it is something to avoid due to practical concerns. If you have a disagreement with someone on Slack, send a follow up email and copy your manager so everyone is in a position to explain themselves. Only if they say A and then in the email say B, and somehow this escalated and became a verbal battle, you should then provide screenshots. Although you probably would prefer to be more professional about it. And of course, if the same person continuously tries to do stuff "under the radar" on Slack just to go back on their word, stop having those conversations and move them to email with CC.
But if you share a copy of the opinions I expressed with third parties without my consent, I will just stop talking to you about this and our further communication will be either "yes", "no" or "call me". You will never again get me to talk to you "in private". You sharing a screencap of our conversation on a tool for work is absolutely legal and I have no legal right to privacy there. The same way I have no right to privacy if I tell you something over a coffee in the canteen. But if you turn around on the spot, run to your boss and tell them what I said over coffee in the canteen verbatim, I will stop having those talks with you immediately.
Sharing slack conversations as an image might probably sound bit weird, and others might feel that you cannot be trusted. Even though its an office environment some don't treat IMs in the same way as Email.
For example, I once had a Slack conversation with a colleague who was being rude and difficult. I decided to send my manager a copy of the transcript of the conversation. If I had only given my manager a summary of the conversation, then perhaps he might think that I was either exaggerating or misinterpreting what my colleague had said. But with a copy of the transcript, my manager could see exactly what my colleague said, and that I wasn't exaggerating or misinterpreting anything.
Two: you shared the conversation. Instead, you should have, in your own words, summarized the conversation, explained what you believe the problem is, explained what you have tried to solve the problem, explained why that didn't work. Most importantly, you should have provided your boss with a solution, if at all possible.
If, and only if, your boss actually needs to see every single of word of everything that was said in the entire conversation to make their decision, then, and only then, can you share the conversation in addition to what I wrote above, and in a manner that makes sense (i.e. as text or as a link to the actual conversation).
While it is true (at least in some jurisdictions) that for any work-related conversation (more precisely, communication using employer-owned devices and/or resources), there is no expectation of privacy, what most people take that to mean, is that the IT department can, if necessary, see the entire communication. You are not the IT department, and also, it was arguably not necessary. So, again, while it is true that there is no expectation of privacy for work-related communication, the fact that a co-worker shared a "private" communication between two people is at least weird, and I can understand if that colleague feels their privacy and trust were violated.
It is very likely that your boss has the rights to read your conversations anyway. However, they can decide by themselves whether or not they make use of that right. And most bosses will not. By sending the conversation, you have forced the issue.
The CloudFuze platform makes transferring conversations from Slack to Google Chat easy. This is great news for businesses looking for a direct tool to switch from Slack to Google Chat. It supports migrating all the Slack Workspace direct messages and channels, including emojis, timestamps, user mentions, replies, files, etc.
Read here for more details about how CloudFuze helps organizations migrate effortlessly from Slack to Google Chat while preserving historical context and data.