Skip to main content
Configure submission actions on the button’s Open Modal action. A submission can dispatch to a webhook destination, update the originating message, or do both.

​
Values are keyed by action ID

For a multiline input whose action_id is reason, use {{submission.values.reason}}. Labels are user-facing text and are not stable field keys. A payload template can be:
Values depend on the input type: text/date/time values are strings, while multiple-choice inputs can produce arrays. Confirm the rendered payload in a test before defining the receiver’s validation rules. See all payload variables.

​
Saved is not delivered

Submitting an authored modal saves one receipt per Slack workspace and modal view, then closes the modal. Webhook and message update results arrive asynchronously in interaction history. A closed modal confirms that the input was saved; it does not confirm that the receiver processed it. Retries of the same view reuse the original receipt and first accepted values. Opening a new modal permits another intentional submission, even with identical values. Webhook payloads can reference {{submission.id}}, and each request includes X-LithoBlocks-Submission-Id for receiver correlation. A failed message update does not cause the webhook to be sent again. Component status pending means accepted work is waiting for delivery. uncertain means the outcome needs review: inspect the receiver before submitting again. Failed and uncertain attempts are not automatically retried, including when a destination has retry settings. Submission ownership is retained with its receipt; deleting receipt history removes that protection. The legacy close_on_submission field remains accepted, but saved submissions always close. close_behavior controls when the message update runs after a confirmed webhook result: on_success (also when no webhook is configured), on_error, or always. Unknown webhook outcomes skip the message update. These rules apply to authored interactive modals; slash-command send forms use a separate handler.

​
Verify the full flow

  1. Open a fresh modal from a test message and submit a unique test value.
  2. Check interaction history for the receipt and each component’s outcome.
  3. Confirm the receiver recorded the receipt ID before treating the workflow as complete.
  4. Check that the originating message changed under the configured close_behavior.
  5. Test a receiver failure and ensure your application does not interpret a closed form as successful approval.
Modal API · Message updates · Troubleshooting