Include Slack Message Information in sendAndWait Response Output

Feature Requests
1

The idea is:

I would like the n8n Slack node’s sendAndWait functionality to include the original Slack message information in its output, alongside the form data it currently returns. Specifically, I want to receive the same response object that is returned by the Slack postMessage API when using sendAndWait.

My use case:

I am currently using the Slack node’s sendAndWait functionality to send messages and collect responses. While the node correctly returns the form data when a response is received, it does not include any information about the original message that was sent. This makes it difficult to reference or manage the original message in subsequent workflow steps.

For instance, if I need to update the original message, add reactions, or reference its timestamp/channel in follow-up actions, I currently don’t have access to this information in the node’s output.

Specifically, I’m trying to track the progress of requests by adding reactions to the original Slack messages when responses are submitted. I want to visually indicate the status of each request (e.g., adding a :white_check_mark: reaction when completed) but currently cannot do this efficiently without the original message information being included in the sendAndWait response.

I think it would be beneficial to add this because:

This enhancement would solve several problems:

  1. It would eliminate the need to use separate nodes to track message information
  2. It would allow for more complete message lifecycle management within a single workflow
  3. It would make it easier to build workflows that require referencing both the original message and the response
  4. It would provide consistency with other Slack API integrations, which typically return complete message objects

By including the Slack postMessage API response in the output, we would have access to critical metadata such as message timestamp, channel information, and other properties that are essential for advanced Slack workflow automation.

Any resources to support this?

The Slack API documentation for postMessage shows what information should be included: chat.postMessage method | Slack

The current sendAndWait response only includes form data but doesn’t include message metadata like:

  • ts (timestamp)
  • channel
  • message properties
  • API response metadata

Are you willing to work on this?

I’m not able to implement this myself, but I would be happy to test any implementation and provide feedback on how it works in production workflows.

2

I was about to make a new post for this same concept. I’ll repost here and upvote your topic instead.

The idea is:

Improve the Human in the Loop Slack integration by including the Channel ID and Message Timestamp in the output, allowing users to update the original Slack message after an approval/decline action.

My use case:

When using the Human in the Loop node in n8n to send Slack messages with “Approve” or “Decline” buttons, the response webhook only returns a boolean (approved: true/false). It does not provide the original message’s Channel ID or Timestamp, so there’s no way to update the message in Slack after a button is pressed.

I think it would be beneficial to add this because:

Without the ability to update the message, users are left with stale messages in Slack that continue to show “Approve” or “Decline” buttons—even after an action has been taken. Worse, Slack displays an error saying “Slack cannot handle payload”. This degrades the user experience and creates confusion.

By providing the Channel ID and Message Timestamp, workflow creators could cleanly update or replace the Slack message to indicate the decision has been made.

Any resources to support this?

  • Slack message update API: chat.update method | Slack

  • Example error message from Slack: “Slack cannot handle payload”

  • n8n forum posts related to similar complaints (can be added here if you have links)

Are you willing to work on this?

Yes, if guidance is provided on how to extend the output from the Human in the Loop node or access underlying message metadata.

2 Likes
3

yes this is better if you implement this