openclaw - 💡(How to fix) Fix [Feature]: Add Slack Modal Support for Interactive Workflows

Summary

Add first-class support for Slack modals so workflows can collect structured user input through Slack’s native modal UI instead of relying on repeated message prompts. This would enable cleaner confirmations, form-style input, validation, edits, and multi-step interactions inside Slack.

Problem to solve

Slack workflows often need to collect structured input from users, but without modal support, that input has to be gathered through normal message replies or repeated prompts.

This makes workflows harder to use when they require multiple fields, confirmations, edits, or validation. Users may skip required details, provide information in inconsistent formats, or need several follow-up messages before the workflow can continue.

Slack already provides modals as the native solution for this type of interaction, but without support for them, integrations are limited to less efficient chat-based input patterns.

Proposed solution

Add first-class support for Slack modals using Slack’s native views.open, views.update, and views.close APIs.

At minimum, this should allow workflows to:

• Open a modal in response to a Slack interaction • Define modal content using Slack Block Kit • Include common input elements such as text fields, selects, checkboxes, date pickers, and time pickers • Receive modal submission payloads • Expose submitted values back to the workflow or agent • Update or close an existing modal when needed • Handle validation errors on submission

This would let Slack workflows collect structured input in a native UI instead of relying on repeated message prompts.

Alternatives considered

Example implementation idea:

Add a Slack action/tool that can open a modal using Slack’s views.open API, then route view_submission payloads back into the workflow.

// Example: open a Slack modal from an interaction payload

async function openSlackModal({ slackClient, triggerId }) { return await slackClient.views.open({ trigger_id: triggerId, view: { type: "modal", callback_id: "example_modal_submit", title: { type: "plain_text", text: "Example Form" }, submit: { type: "plain_text", text: "Submit" }, close: { type: "plain_text", text: "Cancel" }, blocks: [ { type: "input", block_id: "summary_block", label: { type: "plain_text", text: "Summary" }, element: { type: "plain_text_input", action_id: "summary" } }, { type: "input", block_id: "priority_block", label: { type: "plain_text", text: "Priority" }, element: { type: "static_select", action_id: "priority", options: [ { text: { type: "plain_text", text: "Low" }, value: "low" }, { text: { type: "plain_text", text: "Normal" }, value: "normal" }, { text: { type: "plain_text", text: "High" }, value: "high" } ] } } ] } }); }

Then handle the submitted modal values:

// Example: handle Slack modal submission

async function handleSlackViewSubmission(payload) { if (payload.type !== "view_submission") return;

const values = payload.view.state.values;

const summary = values.summary_block.summary.value;

const priority = values.priority_block.priority.selected_option.value;

return { summary, priority, userId: payload.user.id, callbackId: payload.view.callback_id }; }

Support could be implemented by exposing a Slack modal action that accepts:

• trigger_id • callback_id • modal title/submit/close text • Block Kit blocks • optional private metadata

The integration would call Slack’s views.open API, then listen for view_submission events and expose the submitted view.state.values back to the workflow or agent.

This would allow developers to define modals using normal Slack Block Kit JSON while keeping submission handling inside the existing interaction/event pipeline.

Impact

This affects Slack users and integrations that need to collect structured input from users, especially workflows using interactive messages, bots, agents, or automation tools.

Severity is moderate to high depending on the workflow. For simple notifications it is only an annoyance, but for workflows that require several pieces of input or confirmation, the lack of modal support can block a clean implementation.

This pain occurs whenever a workflow needs form-style input, confirmation, edits, or multi-step interaction inside Slack.

The practical consequence is extra manual back-and-forth in channels or DMs, more opportunity for incomplete or incorrectly formatted responses, noisier conversations, and slower workflows. Modal support would reduce friction, improve reliability, and make Slack-based workflows feel more native.

Evidence/examples

Slack already supports modals as a native interaction pattern through Block Kit and the views.open / views.update APIs. Many Slack apps use modals for structured input because they are cleaner and less error-prone than collecting information through message replies.

Example scenarios where modal support would help:

• A workflow needs multiple required fields before continuing • A user needs to review and confirm an action before it runs • A bot needs structured values like text, dropdown selections, checkboxes, dates, or times • A user needs to edit existing structured data • A multi-step workflow needs to avoid cluttering a channel or DM with several follow-up questions

Without modal support, these workflows have to rely on repeated chat prompts, which can lead to missing fields, inconsistent formatting, extra clarification messages, and noisier Slack conversations.

Additional information