# Workato actions for Slack

Workbot actions allow Workbot to post notifications into a specified channel when there are events to take note of, or respond to a command.

Workbot supports 10 actions:

# Block kit compatibility

Blocks can be used together with existing message attachments present in the Post command reply and Post message.

For more information, see Block kit.

# Post command reply

Post command reply allows you to customize how Workbot replies when an event is completed. This reply can be a simple message about the task completion, or a prompt for the user to take a subsequent action once the first has been done, for example, after retrieving data for a custom account in Salesforce, ask if the user wishes to copy that information across to another application.

# Blocks

You can stack "blocks" and customize the order and appearance of each block, as well as the elements within each block. Blocks with message attachments

# Compatibility with message attachments

Post message and post command reply previously used message attachments to construct messages. Blocks can be used together with message attachments.

You can optionally provide secondary attachments, which will display below any defined blocks.

# Behavior of blocks when used with message attachments

  • When both blocks and message attachments are defined, blocks will always appear above message attachments. Blocks with message attachments

  • When any blocks are defined, any input in the Message text field will be used as the Slack notification message.

Message text

The following table lists the fields available in a Post command reply action.

Field Explanation
Blocks Build a rich, interactive message using Slack's block kit. View the list of supported blocks.
Message text When no blocks are defined, text in this field will be displayed before any secondary attachments.

When blocks are defined, text in this field will be used as the Slack notification message.

Supports Slack mrkdwn and emojis.
Multiple attachments If set to Yes, allows you to dynamically generate an array of secondary attachments. This array will be merged and posted as 1 single message.

To use it, pass a list datapill into the Attachment source list field, then map the corresponding Message attachments, Attachment fields, Buttons, and Message menu fields with datapills of records from the same list.
Secondary attachments Message attachments Pretext Text that appears above the message attachment block.
Author name Small text used to display the author's name, displayed above the title.
Author link A valid URL that will hyperlink the author_name text. Will only work if author_name is present.
Author icon A valid URL that displays a small 16px by 16px image to the left of the author_name text. Will only work if Author name is present.
Title Title of message. Supports Slack mrkdwn and emojis.
Title link Allows you to embed a link in the title. Provide the public URL of a page you want the user to be brought to when clicking the link
Attachment text Main body of the message. Supports Slack mrkdwn and emojis.
Attachment color Color displayed with the message to indicate message's importance or type.

Good = Green
Warning = Amber
Danger = Red
Image URL URL of an image that will be displayed below the main body of the message.
Thumb URL/Application URL of an image that will be displayed to the right of the main body of the message.
Footer Some brief text to help contextualize and identify an attachment. Limited to 300 characters, and may be truncated further when displayed to users in environments with limited screen real estate.
Footer icon A valid URL to an image file that will be displayed beside the footer text. Will only work if author_name is present. We'll render what you provide at 16px by 16px. It's best to use an image that is similarly sized.
Attachment fields Name-value pairs displayed in a 2-column grid.
Buttons Buttons display below the main body of the message. Buttons are primarily used to invoke a command, executing another bot command recipe. You can define the button label, the command to be executed, and parameters to pass when the button is clicked.
Message menu A drop-down menu, displayed below the main body of the message. Each menu option can be used to invoke a command, executing another bot command recipe.  You can define the display of each option, the command to be executed, and parameters to pass when the menu option is selected.
Send only to the user Posts as an ephemeral message, viewable only to the user.
Replace original Replaces the original message. If the original message was an ephemeral message, the replaced message will also be ephemeral. Regular messages cannot be replaced with ephemeral messages.
Delete original Deletes the original message.

# Post message

This action will post a message response to a user who invokes a command. The post message action is similar to that of the post command reply, but has more features.

Use post message if you:

  1. Are not using a Workbot command trigger in your recipe

  2. Want to dynamically post the message to a member (user ID) or conversation (conversation ID)

  3. Want to use advanced features like updating a previous message or posting/updating messages in a thread.

# Channel name/DM

Channel name/DM field allows you post a message in a specified Slack channel or direct message (DM). Use the Channel/DM datapill from a Post command trigger, or key in the channel name for example, #general or username for example, @john.

Message to update example Message to update example

# Advanced section

The advanced section has 2 fields:
Message to update and Thread ID.

  • # Message to update

    Message to update allows you to overwrite a previously posted message from an earlier action step. Simply use the Message ID datapill from a Post command trigger, Post message action or Post notification output datatrees.

    Message to update example Message to update example

  • # Thread ID

    Thread ID allows you to post a message within an existing thread in Slack. Simply use the Thread ID datapill from a Post message or Post notification output datatree.

    Thread ID example Thread ID example

    If you don't see Thread ID, make sure it's checked in the 'Add/remove optional fields' section at the bottom of the post message action step:

    Thread ID example

# Post notifications

This action allows you to define which Slack channel to post customized notifications to. By default, Workbot posts direct messages only to the user who installed Workbot. Note, it is also possible to subscribe from a channel (where Workbot participates) to these notifications.

The fields available are simillar to that of the Post command reply action, with all the typical fields you see in a Slack message. However, there is the addition of the field Notification filter. This field allows you to set parameters for filters, which acts like a trigger filter for sending out notifications (i.e. the notification will only get sent when the set criteria is met).

# Download attachment

This action allows you to download attachments from Slack, received as input to New command trigger. Make sure command parameter for uploaded content has type file, for example, attachment type:file. Pass file URL from New command output into the URL field to get attachment content. Then you may further pass this file content to Dropbox, Box, or other connectors to upload them as files.

# Return menu options

This action allows you to dynamically generate menu options, then return them to a dynamic menu in a Slack dialog.

For Workbot command recipes that invoke dialogs, a select field can be defined with dynamic menu options.

Dynamic menu A Workbot command recipe with dynamic menu options

After retrieving a list of records from another app (for example, Salesforce), you can return them back to the dynamic menu by using the Return menu options action.

Return menu options recipe Retrieving Salesforce opportunities before returning them as menu options back to the Slack dialog with the dynamic menu

Hence, this action should always be paired with a New dynamic menu event trigger.

# Input

By default, you can specify a static list of menu options by adding menu options 1-by-1.

Add static menu option Adding static menu options 1-by-1

However, you can create a dynamic list by changing the input mode to dynamic. Simply pass a list datapill from the ouput of a previous action step.

Return menu options recipe Configuring dynamic menu options

Returned menu options are in an ungrouped list by default.

Ungrouped options in the recipe Ungrouped options in recipe

Ungrouped options Ungrouped options in Slack

When returning menu options, you can group menu options together by setting Group menu options? to Yes. This will require you to specify Title of group for each group you add.

Grouped options in the recipe Groups options look in recipe

Grouped options Grouped options in Slack

# Post attachment

This action will post a file attachment to a specified channel, DM, or thread. You can also include a simple message together with the file.

Upload file with simple message A short message before the Chat history.json file

The following table lists the fields available in an Upload file action.

.
Field Explanation What goes in here
Channel name/DM Upload a file to a specified Slack channel or direct message (DM). Use the Channel/DM datapill from a Post command trigger, or key in the channel name for example, #general or username for example, @johndonahue.
Initial comment Simple message to post together with the uploaded file. Include a simple message to give more context to your file.
File name Name of your file. Provide a name for your file, for example, chat_history.json. This will be the name of the file when any user downloads it from Slack.
File type Type of file Provide the file type of your file. For the full list of file types which Slack supports, see here.
File content Contents of the file Use a Content datapill from the output of preceding action or trigger, for example, a File contents datapills from a Google Drive Download attachment action.

Title Display title of the file Displays the title of the file. If left blank, the File name will be displayed instead.
Thread ID Uploads the file within an existing thread Use the Thread ID datapill from the output datatree of a Post message or Post command reply to upload the file to an existing thread.

If no thread exists yet, use the Message ID datapill instead. This will create a new thread for the uploaded file.

# Open/update or push modal view action

This action allows you to build rich, interactive, and dynamic modals that collect information from users in a structured manner. Modal views are built using blocks. Modal example

You can open a new modal view, update an existing view, or push a new view on top of an existing one by setting the Modal action type to open, update, or push respectively. Open/update or push modal view

For all modal action types, Trigger ID is always required. Trigger IDs are generated by Slack when users interact with:

  • buttons,
  • menus,
  • overflow,
  • select menus,
  • datepickers,
  • radio buttons,
  • shortcuts,
  • message actions,
  • slash commands,
  • modal view submissions

Opening a modal view requires Trigger ID, obtained from the output of a New command trigger. Trigger ID Trigger ID for opening modal views (found in the New command trigger)

Updating a modal view also requires Trigger ID, but you must also specify the View ID of the view to update. This View ID can also be found in the New command trigger datatree, under Modals. Trigger ID and View ID for updating modal views Trigger ID and View ID (both found in New command trigger) for updating modal views

Pushing a modal view (on top of an existing one) requires Trigger ID. However, this Trigger ID must be generated from an existing view. Trigger ID for pushing modal views Trigger ID for pushing modal views (found in New command trigger)

# When to update modal views

Typically, bot commands update the active view they exist in (View ID). Update modal Making changes on the active view

In contrast, modal submissions usually update the root view (Root View ID) or the previous view (Previous View ID). These views can be found in the New command trigger datatree, under Modals.

Modals object in New command trigger datatree Root View ID and Previous View ID found in the New command trigger

WARNING

When a view is submitted, it closes by default. Use the correct View ID when updating views in response to view submissions.

# When to push modal views

Typically, bot commands push views on top of the active view they exist in (View ID). The View ID can be found in the New command trigger datatree, under Modals.

Push modal Making changes on the active view

Modals object in New command trigger datatree Root View ID and Previous View ID found in the New command trigger

WARNING

When a view is submitted, it closes by default. Take care to only push a modal view on top of an active view.

# Open/update or push modal view action input

The following table describes the configuration when working with Modals.

Input Description
Trigger ID (required) Modal views can only be opened by interactive components (like buttons & menus), modal submissions, message actions, shortcuts, and slash commands. When users interact with or use these features, a trigger ID is generated. You can grab these from the New command trigger datatree under the Modals object.
Modal action type (required) You can open a new modal view, update an existing view, or push a new view on top of an existing one by setting the Modal action type to open, update or push respectively. This can be set dynamically by toggling to Custom value. View ID will be ignored if the action does not require it (for example, opening/pushing a modal view).
View ID (optional) To update an existing modal, specify the view ID of the view you want to update. This field is ignored when opening or pushing modal views.
View Title of modal Title of the modal view. Up to 24 characters only.
Blocks An array of blocks you can stack and rearrange.
Submit view Submit command Command to invoke when users do a modal submission.
Hidden parameters When users submit modals, you may want to pass some parameters (for example, the user ID, opportunity ID) so that the downstream recipe has context to work with.

You'll need to define these parameters in the New command trigger in the downstream recipe so that it's prepared to receive them. The parameter names in both upstream & downstream recipes must match.

Parameters can be passed either in comma-separated name-value pairs, for example, name: John Smith, user_id: AB12345 or in JSON, for example, {"opportunity_id": "OPP1234567"}. When using JSON, you can also pass array or object parameters.

It's important to ensure the parameter names and data types match their upstream counterparts, for example, when using opportunity_id as a singleline input in the view of modal (rendered in an upstream recipe), also specify opportunity_id as a string parameter in the New command of the downstream recipe.
Submit button label Label of the submit button. Up to 24 characters only.
Close button label Label of the close button. Up to 24 characters only.
Clear on close Clicking on the close button will clear all views in a modal and close it. Defaults to false.
Notify on close Sends a view_closed event when a user clicks the close button. Defaults to false. Use the New event trigger to listen to this event.
Advanced Private metadata For advanced users. Used to pass sensitive data. This field is encrypted and hidden to users. Max length of 3000 characters.
Callback ID For advanced users. Used to reference the view submission event in downstream recipes. Max length of 255 characters.
Hash A unique value you can optionally use when updating modals. When provided, the hash is validated such that only the most recent view is updated, ensuring the correct view is being updated when updates are happening asynchronously. This field is ignored when opening or pushing modal views.

# Publish app home view

App homes are a great way for users to interact with your bot. Rather than using bot commands, slash commands, or shortcuts, provide users with a rich app home surface for them to interact with.

App home example App home for ApprovalsBot

The Publish app home view action allows you to publish an app home view for your Enterprise bot using blocks.

Publish app home view action Publish app home view paired with New event trigger (app_home_opened event)

This action is typically used together with a New event trigger that is configured to listen to app_home_opened (opens new window) events. app_home_opened event example app_home_opened event example

App home views are unique to each user who visits your bot's app home. This is why the User ID is required when publishing app home views. You can take advantage of this fact by publishing app home views that display information that is scoped to the user, for example, showing approvals that only the user has the authority to approve.

App home example App home greets and displays data scoped only to the specific user

# Update blocks by block ID

This action allows you to update, replace or remove specific block(s) from views on any surface (messages, app homes, and modals) without recreating the entire view. Multiple blocks can be updated, replaced, or removed in one go. It is also possible to replace single blocks with multiple blocks.

TIP

Specifying block IDs is optional when posting messages, publishing app homes, or launching modals. But if certain blocks need to be updated in the future, give them a block ID.

To update blocks,

1

Specify the surface that the original block is in. Message, App home, and Modal surfaces are currently supported.

2

Pass the JSON of the original message or view.

1

For Messages, pass the Original message JSON datapill from the output of the New command trigger or Message JSON from the output of the Post message/Post command reply actions.

2

For App home, pass the View JSON datapill from the output of the New command trigger (under Modals & App home) or the app_home_opened event from the New event trigger.

For Modals, pass the View JSON datapill from the output of the New command trigger (under Modals & App home) or the View JSON datapill from the Open/update or push modal view action.

3

Add 1 or more block(s) to update.

4

Specify the block ID of each block to be updated/removed.

5

Should the block be removed? If so, set it to Yes. Otherwise, this defaults to No.

6

Define the replacement block(s).