Is there a way, by means of some setting or programmatically, to allow a user on Slack to confirm that the user really wants to send a message before the message is sent? Often times we end up sending messages on the wrong channels or DMs. How can we prevent these?
Assuming by "send a message" you mean "post a message" to a channel.
Via Settings
No. There is no Slack setting to enable confirmation before a message is posting.
Programmatically
No. Its possible to retrieve all messages that are posted to a channel with a Slack app (e.g. via Events API) and then react to them, but only after the fact. To the best of my knowledge it is not possible to insert some kind of confirmation logic into the standard process of posting a message.
Related
What we are trying to do
I am working on automation which posts messages to a Slack channel using Incoming Webhooks on a custom Slack App. The messages mentions people.
What works
We can send a message just fine, it has formatted content, and usernames are correctly resolved using the link-names flag.
What isn't working
The whole point of the notification is to inform a dynamic set of people about something they should care about. The set of people we tag varies hugely (think people who contributed to a pull request) and so not all possible recipients are in the channel these automated messages go to.
We assumed that given the usernames are being directly #-mentioned, they would be notified by Slack. However, two of the users we've tested with and #-mentioned confirm they never received a notification they had been tagged.
This is different to "human" behaviour, where if you #-mention someone in Slack, you get a little message reminding you that person isn't in this channel and offers to invite them or let them know.
As far as we can tell, sending the message programmatically is doing the equivalent of "Do nothing" in the picture above. I want to do either of the other two options, preferably "Let them know".
How can I notify people they've been mentioned? I've looked at all the API documentation and nothing discusses notifying users who aren't in the channel that they are mentioned.
This can't be an uncommon issue.... right?
Notes:
We aren't directly calling chat.postMessage, it's just the only documentation on link_names I could find to link to. We are using Incoming Webhooks, which has minimal documentation on the parameters - it seems to be the same as chat.postMessage.
We would prefer not to move off Incoming Webhooks, but we can do a custom integration with the API if we have to.
You need to invite the user to the channel first, using the Python client that's:
client.channels_invite(
channel=channel_id,
user=user_id
)
In a Slack conversation, is it possible to click on a button to send a message to the Slack channel?
The Slack conversation could be:
The user types a word (or message)
A slackbot shows some text and two buttons
The user clicks on a button to send a TEXT message to the Slack channel
The Slackbot reacts on the 'action' message.
It is not possible to create an REST service for my Slackbot, because the Slackbot is behind a firewall. So, registering commands is not possible.
So sending a message as the result of a button click is needed. The Slackbot can react on that message.
I read that attachments could be a good way to do this, BUT the is 'outmoded'.
I tried to send an secondary attachment, which is outmoded, but that was not possible.
The next approach was adding a webhook. So pushing a button resulted in using the url, but that is of course not possible because I cannot send a POST request via a simple (get) url.
Please give a short example.
This will not work.
Every interactive feature (e.g. buttons) require your app to be able to receive POST requests from Slack through the public Internet. Since you say you can not provide that (e.g. behind a company firewall) you will not be able to use any interactive features.
See also this answer: How to integrate internal APIs (Not accessible outside office network) to slack slash commands
Whenever my app posts ephemeral message to Slack channel (in response to a query by a user), I am unable to get the timestamp of my Slack app response. As I want to delete it once the user has made a selection using one of the buttons. Although I have subscribed to 'message.channels' event, I don't get a notification to my app whenever my app posts in the channel (in response to the user input), therefore, I am unable to get the timestamp of the message which I'll use to delete it. All I want is the timestamp of the message posted by my app so that I can delete it but I am unable to receive the timestamp. Please help!
For e.g. in Giphy app for Slack. Let's say the user invokes the app by calling '/giphy [dog]' where 'dog' is just an example of a search term. The app responds by sending a gif and user can either send it, shuffle to the next one or cancel it. I want a similar capability of cancelling the app response but I need the timestamp of the message in order to do so therefore I am asking for help.
Thanks.
Your approach can not work, because Slack is handling ephemeral messages differently from "normal" messages. They are only visible by one user and can not be modified by API methods (e.g. deletion).
But of course its possible to replace ephemeral messages. Here is how:
Your app can just reply to the interactive message request from Slack with a new message. That new message will by default override the original message including ephemeral messages.
You can reply in two ways:
Directly reply to the request from Slack with a message within 3 seconds
Send a message to the response_url from the Slack request within 30 minutes.
See here for the official documentation on how to respond to interactive messages.
This approach works both with interactive messages and slash commands.
See also this answer for a similar situation.
I am using an Azure Function to send a Proactive message to the client. How do i "reset" a conversation when a Proactive message is sent.
Within the bot, a user might be prompted for something (ex. time of day). A proactive message may get sent to them before they respond. In this scenario, I would like to reset/cancel the previous dialog and start fresh.
I am already able to reset the dialog using CancelAllDialogsAsync which works fine for user-driven messages.
I am sending my proactive message using ConnectorClient, which bypasses the framework, and sends directly to the client, thus never hitting my middleware to reset the dialog.
How can I get the proactive message sent to the framework (i can send the response from the bot no problem)
I would highly recommend you solve this by having your function send your bot a backchannel event under the context of the ConversationReference via the ConnectorClient. This way the bot maintains ownership for all the details about state and what should happen when this event occurs rather than that responsibility leaking to the function. The bot then watches for this custom event and responds to it however it sees fit.
If you need any more details let me know and I'll update my answer.
On facebook Chatbot or others platform we can send message directly to the user.
So for one question we can send multiple answer.
Now, that i'm developing for Google Home, I need to do the same.
I didn't find this opttion.
Dialogflow HTTP call to my server is the only output available.
So is there anything i missed to send message back to user in case I have a multiple messages answer?
(Or do I have to bufferise very message my hook creates before sending it back?)
Thanks
The conversation model for the Google Assistant is different - you can only send a message to the user in response to the user sending you a message. You can only send a single response, but it may have multiple parts (up to two Simple responses, containing messages, plus other features such as cards and carousels).
If you need to send multiple things back - you may need to rethink how you're doing it or how much you're sending back at a time. The Assistant is primarily for audible responses, and a long audible response is generally not a good UX.