Overview

This Block Kit beta kicks of a series of improvments and new features to block kit, bringing some of the most requested feedback to you. This beta will include a number of additions to Block Kit that will roll out in a staggered manner over the next few weeks. This document will serve as your source of truth for this beta regarding dates for feature and how to use these new features. Our goal for this beta is to validate assumptions we’ve made while crafting these API changes and gather your input regarding the new functionality we’re bringing to Block Kit. Please provide feedback on these features using this link.

Beta Features

Input Blocks in App Home

For use in: App Home

You can now utilize Input Blocks in your App Home. To utilize an input block in your app home, add the dispatch_action: true flag to your input block definition to receive block actions from input blocks in app home. As there is no submit functionality in App Home, this will be the only way your app will receive the value of inputs in these blocks.

Sample App Home View:

{
  "type": "home",
  "blocks": [
    {
      "type": "header",
      "text": {
        "type": "plain_text",
        "text": "Inputs in App Home!",
        "emoji": true
      }
    },
    {
      "type": "input",
      "dispatch_action": true,
      "element": {
        "type": "plain_text_input",
        "dispatch_action_config": {
          "trigger_actions_on": ["on_character_entered"]
        }
      },
      "label": {
        "type": "plain_text",
        "text": "Label",
        "emoji": true
      }
    }
  ]
}

Full State in View Submission

For use in: Modals

Previously, when your app received a view_submission payload, the state value would only contain the state of any input blocks in the view. This meant that you were missing the state of any stateful elements in other interactive blocks from that view. Now, view_submission and block_action payloads will include a full state property that will include all stateful elements, not just input blocks.

Below is a sample payload from a modal with a multi_conversations_select element in a section block and a plain_text_input element in an input block:

"state": {
  "values": {
    "section_block_id": {
      "multi_convos": {
        "type": "multi_conversations_select",
        "selected_conversations": ["G12345"]
      }
    },
    "input_block_id": {
      "plain_text_action_id": {
        "type": "plain_text_input",
        "value": "test123"
      }
    }
  }
}

Checkboxes and Radio Buttons in Messages

For use in: Messages

Checkboxes and Radio buttons have previously been available for use in Modals and App Home. This feature allows you to use checkboxes and radio buttons in messages, as a part of section and action blocks. Messages are collaborative spaces in channels, allowing many users to interact with your app’s content simultaneously. Checkboxes and Radio buttons will allow you to create new UX experiences, such as collaborative lists and new types of polls.

API Reference

To utilize checkboxes and radio buttons in messages, add either of these elements to section or action blocks.

Example Block Kit JSON:

 {
       "type":"actions",
       "elements":[
          {
             "type":"checkboxes",
             "options":[
                {
                   "text":{
                      "type":"plain_text",
                      "text":"Option 1",
                      "emoji":true
                   },
                   "description":{
                      "type":"plain_text",
                      "text":"*this is plain_text text*",
                      "emoji":true
                   },
                   "value":"value-0"
                }
             ]
          }
       ]
    }

API Specifications:

• Checkboxes and radio buttons will be available in the following surface areas once in messages:
  • channels, all threads, thread message view, broadcasted threads, pinned messages, shared messages, saved messages, activity pane, search results
• Content inside a checkbox or radio button is indexed and is searchable from inside Slack
• Checkboxes and Radio Buttons will appear as disabled to users that are not a member of the channel where the content was posted.
• If a user repeatedly clicks on a checkbox or radio button, their clicks will be debounced and you will only receive one block_action with the final state of the element.
• On mobile, checkboxes and radio buttons will be truncated to five options.
• Checkboxes and Radio buttons should respect the "confirm" property - if present, the checkbox or radio button will only show as checked, and the API call will only be sent, if the user "confirms" the modal

Disclaimers

• Hashing has not yet been implemented for checkboxes and radio buttons. You might find that during this beta you are updating messages based on stale user data. A hashing solution will be implemented by General Availability.
• Truncation rules on mobile might change during the course of this beta.

Input Blocks Dispatching Actions

For use in: Modals

Input Blocks are utilized in Modals, providing users with a surface area to input plain text input, select users, conversations, dates, etc. Historically, selections in an input block were provided to developers in the view_submission payload. With this change, input blocks will behave in a similar manner to action blocks. For every user input and selection, a block_actions payload will be fired with the contents of the input, allowing for realtime updates in a modal.

This feature is available for all input blocks. There is further configuration available for plain text input blocks, allowing you to customize when you would like to receive block_action payloads.

In addition to this change, we have made the following improvements to Input Blocks:

• Elements in Input blocks now respect the confirm property. If supplied, the user will have to confirm their action before it will be dispatched.
• Some elements in Input blocks that are marked as optional have a “clear” option. This should also dispatch an action.
• Actions are now debounced, meaning if users spam any element on any client, a single API call will be fired to reflect the final state.

API Reference

To receive block_actions from input_blocks add dispatch_actions = true at the input block level. This flag will default to false in order to maintain backwards compatibility with previous input block behavior.

Example Payload:

    {
        type: "input",
        dispatch_action: true,
        element: {
          type: "channels_select",
          placeholder: {
            type: "plain_text",
            text: "Select channels",
            emoji: true
          }
        },
        label: {
          type: "plain_text",
          text: "Channels select in an input block dispatching actions",
          emoji: true
        }
      }

Plain Text Element Special Cases:

With plain text elements, you are able to customize when you will receive block_actions payloads, allowing you to tailor these interactions to your specific use cases. To customize, you will need to add a dispatch_action_config object at the element level. This object is only functional in conjunction with the dispatch_actions flag on input blocks on plain_text elements. Providing a dispatch_action_config without a dispatch_actions will result in no actions being dispatched.

Dispatch Action Config Object:

Note: If you are dispatching actions from a plain_text_input element in an input block on enter pressed, hint text will now appear underneath explaining to the user to press enter to submit on web and mobile.

Example Plain Text Input Block Schema:

    {
        type: "input",
        dispatch_action: true,
        element: {
          type: "plain_text_input",
          multiline: true,
          dispatch_action_config: {
            trigger_actions_on: ["on_character_entered"]
          }
        },
        label: {
          type: "plain_text",
          text: "multiline Plain Text Input dispatch = true, on character typed",
          emoji: true
        }
      }

Disclaimers/Known Bugs:

1. Input blocks dispatch empty states differently than previous blocks.actions payloads. Most empty states in block_actions from input blocks will send null . This is a known inconsistency that will be fixed. Please be aware that the way empty states are represented may also change.
2. If you are also working on Workflow Builder Steps, you may notice that dispatch customizations aren’t supported in input blocks with plain_text_inputs. This will be fixed and those input blocks with plain_text_input will behave the same as everywhere else at GA.
3. Accessibility testing hasn’t been completed at this point.
4. You may notice some inconsistencies with the initial_* values on web only, and have some trouble updating them. This is a known bug and is being addressed.