Slack Modal Dialog Text Field

Hi, I was wondering how to initiate a slack Modal using pipedream to listen to a trigger then send back an input dialog to enter a text

@yhassanien welcome! I briefly read over this guide, and it looks like this should be possible in Pipedream.

To get this working, you’ll need to create your own Slack app. In Pipedream, create a new workflow with an HTTP API trigger. In your Slack app’s settings, you’ll want to point the Interaction Payloads to the Pipedream HTTP endpoint tied to your trigger step.

If you follow the Slack guide, you’ll see that modal interactions require a “back-and-forth” with Slack: Slack sends an interaction payload to your HTTP endpoint each time the user initiates some action within Slack, and your workflow should respond to that action accordingly.

For example, in step 2, where you receive the payload when the user interacts with the app’s entry point, you’ll want to send an API request to the views.open endpoint with the trigger_id sent in the interaction payload from Slack. You should be able to add a new Node.js code step to your Pipedream workflow (click the + button and choose the option to Run Node.js code), then use Slack’s Node.js SDK to do this (if you’re familiar with Node), or send an HTTP request using an HTTP client like axiossee our HTTP request docs for some examples of how to do that.

Slack’s guide on modals has a great overview of this, and the remaining steps are similar in concept: Slack sends you a request, you handle that request by sending an API request to Slack to take some action.

Let me know if that helps or if you have any other questions about how to accomplish this in Pipedream.

Thanks @dylburger

I followed the steps and I can only send message block also I followed your video on youtube and I am able to send message but when I use the Modal view I get an error invalid blocks
I invited you in if I missed something in my code

Hi @yhassanien , the core issue is that you’re using the Send Message action within Pipedream, and sending an API request to the chat.postMessage endpoint. But Slack requires you send an API request to the views.open endpoint, instead.

Take a look at this example workflow, which uses an action that wraps the views.open API request to Slack. There, you’ll see where to pass your trigger ID and the view payload, which corresponds to the “view” object of the JSON you included in your formatblock step.

You can also add a new Node.js code step and extend this example POST request to the views.open HTTP request from the Slack docs. You can link your Slack connected account to that step so that you can send your Slack token in the Authorization header, as noted in the docs.

Let me know if that helps!

I’ve also been trying for a week to use Pipedream to respond to Slack interactivity events and open modal dialogs. I just can’t seem to get it to work though. I always get a trigger_expired error. I know that Slack has a 3 second timeout on responding to trigger IDs, but I don’t think this is the cause - possibly when there is a cold start but I see a fast execution when the workflow is warm.

I think it is maybe because Pipedream responds with a 200 before I call views.open with the trigger ID…? Maybe that cancels the trigger or something /shrug

@yhassanien did you ever get this working?

@ajedwards like you mentioned, I’ve observed the trigger_expired error when more than 3 seconds have passed between the time the trigger was issued and the time you call views.open (more details here).

Since Pipedream workflows are not “always on”, here’s my best advice for trying to reduce the delta between trigger execution and the views.open call:

  • Call views.open first in your workflow, before any other work.
  • Implement a “warming” workflow that keeps your Slack workflow active
  • When you trigger a “cold” workflow, there are two main things that happen before we run your code: 1) we spin up a new execution environment (no way to decrease this time), and 2) we download any npm packages required by your code. #2 can be eliminated if you limit what you require in your workflow. In your case, you might try only requiring an HTTP library like got (whose package size is small) and make the views.open call in this workflow to keep this workflow incredibly lean. Then trigger another workflow after that call is done that contains the core logic.

Let me know if that helps. I know this is a lot of work just to get a simple API call working. We see use cases like this a lot and we’re thinking about a lot of ways to improve the developer experience here (e.g. see this issue).

1 Like

Thanks for the advice, @dylburger. Some good ideas for me to try.

I’ve done some more reading and it seems like Slack don’t recommend using serverless functions in general to respond to interactivity. It’s something they want to support but don’t advise yet.