Skip to main content

​
Overview

Sometimes a simple Slack message isn’t enough—especially during a fast-moving incident when responders need structured actions, rich context, and guided workflows.
The Send Slack Blocks workflow action allows you to build complete interactive Slack experiences using Slack’s Block Kit framework. With this action, you can:
  • Send richly formatted messages to Slack channels, users, or user groups
  • Provide responders with buttons that open Rootly modals or workflows
  • Thread updates under existing messages
  • Pin important updates
  • Run custom workflows or present custom forms
  • Mirror in-product toolbars directly inside Slack
This action is foundational for teams that want incident responders to take meaningful action without leaving Slack.

​
Action Attributes

Document Image

​
Name

This field is automatically set for you. You can rename this field to whatever best describes your action. The value in this field does not affect how the workflow action behaves.

​
Slack Users

Specify the Slack user(s) you wish to send the custom Slack block to.

​
Slack User Groups

Specify which Slack user group(s) you wish to send the custom Slack block to. All users part of the specified user group(s) will be sent the block. You can read more about Slack user groups here.

​
Channels

This field specifies which Slack channels to send the Slack block to. Some common selections:
  • Setting to {{ incident.slack_channel_id }} will send the block to the Slack channel of the triggering incident.
  • The Liquid snytax {{ parent_incident.slack_channel_id }} can be used for sub incidents and it will send the block to the Slack channel of the parent incident.
  • You can also send blocks to static channel (e.g. #gernal, #alerts)

​
Send as Ephemeral

If selected, your message will be sent as a hidden message visible only to the specified users. A value must be set for the Slack Users or Slack User Groups and Channels when this field is selected. Additionally, the selected users need to be in the specified channels.

​
Pin to Channel

If selected, your message will pinned to the specified channel(s).

​
Message Threading Options

If you want to thread the block under an existing block/message that Rootly has previously sent, you can do so by selecting a parent block/message to be threaded under.

​
Filter Tasks by Workflow

This field is used to filter for the workflow that contains the specific action responsible for sending the parent message. The value in this field will not persist once the workflow is saved, as the Select a Task field is what ultimately determines the parent message to thread under.

​
Select a Task

This field is used to select the specific action that’s responsible for sending the parent block/message. This field determines which block/message is the parent block/message to thread under.

​
Update Parent Message

If this field is selected, the workflow will update the original parent block/message, instead of threading underneath it.

​
Broadcast Thread Reply to Channel

If this field is selected, the threaded block will also be broadcased as a new block in the specified channels.

​
Notification Preview

Content in this field will be displayed in the push notifications. This field supports Liquid variables.

​
Blocks

The blocks field consist of the payload that will be send in Slack. Customizing this payload will allow you to build custom messaging. The payload follows the same restrictions as Slack’s block elements do. You can preview and check if your payload is valid by clicking the Preview button. This button will route you to Slack’s Block Kit builder.
The Block Kit builter is a Slack-built application. So, it will not be able to recognize any Liquid variables that you might have referenced in your payload. You will need to use Rootly’s Incident Variable Explorer in conjunction with Slack’s Block Kit builder.

​
Select a Template Dropdown

You can choose any pre-built blocks from the Select a template dropdown field. This is a great starting point to get familiarized with Slack’s Block Kit syntax.

​
Section

Selecting a section will append a pre-built section to your existing payload. Sample text block with markdown enabled 
{
  "type": "section",
  "text": {
    "type": "mrkdwn",
    "text": "Allows for *markdown formatting*: <https://api.slack.com/reference/surfaces/formatting#basics| Slack Markdown Formatting Guide>"
  }
}
Sample image block 
{
  "type": "section",
  "text": {
    "type": "mrkdwn",
    "text": "Some *text* here with markdown support"
  },
  "accessory": {
    "type": "image",
    "image_url": "https://picsum.photos/200",
    "alt_text": "placeholder_image"
  }
}

​
Rootly Action IDs

Rootly provides a rich set of interactive actions that can be triggered directly from Slack messages using Block Kit buttons. Each action is identified by an action_id, which tells Rootly what modal, dialog, or workflow should open when a user clicks a button. These actions allow responders to manage incidents, assign roles, update forms, escalate through on-call systems, publish to status pages, trigger workflows, and more—all without leaving Slack. Selecting an action will append a pre-built action element to your existing payload. Each block option here is customizable. The action_id field must be set to one of the following available values. Incident Editing and Toolbar Actions These actions mirror the primary controls available in the incident toolbar within the Rootly web interface. They allow responders to update key incident attributes directly from Slack, enabling fast and seamless adjustments during active incident response.
Action IDDescription
toolbar_update_incident_summaryOpens the incident summary modal, allowing responders to refine or rewrite the customer-facing summary that appears across Slack, the web UI, and status pages.
toolbar_update_statusLaunches the incident status update modal. This is the primary way to transition an incident through its lifecycle (e.g., In Triage → Mitigated → Resolved) from Slack.
toolbar_update_incidentOpens the full incident editing modal, enabling responders to adjust severity, impacted services, environments, incident type, and any organization-specific fields.
toolbar_available_commandsDisplays the Rootly “available commands” modal, giving responders a quick reference to the Slack commands and actions supported in the incident channel.
archive_incidentArchives the incident. This action should be used when the incident is no longer active and has been formally closed out of your operational workflow.
These actions are most frequently used in workflow-generated Slack messages that serve as toolbars during incident response. Roles, Custom Fields, and Action Items These actions provide access to the deeper, structured metadata associated with an incident. They are helpful when you want responders to supply additional detail, update responsibilities, or manage follow-up work directly from Slack.
Action IDDescription
manage_incident_role_assignments_dialogOpens the role management modal, allowing assignment or reassignment of incident roles (e.g., Incident Commander, Communications Lead, Liaison).
manage_form_field_selectionsOpens the custom fields modal where responders can update any additional metadata your organization configures—such as customer segment, region, or incident classification.
manage_incident_action_itemsProvides an interface for creating, updating, or reviewing incident action items. This includes tasks assigned during the incident or added during retrospectives.
todo_dialogShows the logged-in user a consolidated view of all action items assigned to them across the incident. This is particularly valuable for follow-up and ensuring nothing is missed.
add_feedbackOpens a modal for submitting incident feedback. Teams typically use this after resolution to collect input from responders while context is still fresh.
These actions ensure that critical metadata and structured follow-up work can be captured in real time. PagerDuty, Opsgenie, and VictorOps Responders If your team uses an on-call provider such as PagerDuty, Opsgenie, or VictorOps, these actions allow responders to request additional help directly from Slack. Rootly opens the appropriate native dialog based on the integration installed.
Action IDDescription
pagerduty_respondersOpens the PagerDuty responders dialog, allowing responders to bring additional on-call resources into the incident.
opsgenie_respondersOpens the Opsgenie responders dialog with equivalent functionality.
victor_ops_respondersOpens the VictorOps responder dialog.
add_pagerduty_respondersAlias for the PagerDuty responders dialog; present in some workflows and payload schemas.
add_opsgenie_respondersAlias for the Opsgenie responders dialog.
add_victor_ops_respondersAlias for the VictorOps responders dialog.
Action IDs in this category only function if the corresponding integration is installed and configured. Escalation Flow Navigation Rootly’s escalation modal consists of multiple steps, particularly when working with PagerDuty. These internal action_id values allow navigation between different screens within the escalation dialog.
Action IDDescription
escalate_dialogOpens the primary escalation dialog in Slack. This is the entry point for escalation during an incident.
update_pagerduty_escalate_dialog_respondersNavigates to the step where responders are selected.
update_pagerduty_escalate_dialog_escalateMoves to the escalation decision page, where responders may be paged or re-paged.
update_pagerduty_escalate_dialog_reassignOpens the reassignment step, enabling teams to shift ownership or responsibility.
update_pagerduty_escalate_dialog_create_new_incidentNavigates to the page for initiating a new PagerDuty incident from Slack.
These action IDs are mostly used internally by Rootly during modal interactions, but they are documented here for completeness and for teams that build highly customized Slack experiences. Status Page Publishing These actions open the modal used to publish incident updates to a Rootly status page. The difference between the two is primarily contextual: one is designed for general use, and the other appears when triggered from the incident overview toolbar.
Action IDDescription
update_status_page_dialogOpens the modal for composing and publishing a status page event (e.g., Identified, Monitoring, Resolved).
overview_update_status_page_dialogOpens the same modal, but from the context of the incident overview toolbar.
Either may be used depending on where your Slack block resides. Workflow Reminder Controls Repeating workflow reminders—commonly used for prompting updates, stakeholder communications, or periodic status checks—can be controlled directly from Slack using these actions.
Action IDDescription
pause_reminderPauses a repeating workflow reminder so that it no longer sends notifications.
snooze_reminderSnoozes the reminder temporarily, allowing responders to quiet a notification stream during intense triage.
restart_reminderRestarts a previously paused workflow reminder and resumes its normal schedule.
These actions are useful in time-based or scheduled periodic reminder workflows. Custom Workflows and Custom Forms These action IDs enable deep integration with your team’s automation and custom forms. They allow responders to invoke tailored, organization-specific actions directly from Slack messages.
Action IDDescription
trigger_custom_workflowRuns a custom workflow. This action requires that the Block Kit JSON include a value matching the workflow’s Slack command (found under Advanced Settings for that workflow).
open_custom_formOpens a custom Rootly form in Slack. Requires the value to correspond to a form slug configured in your workspace.
These actions allow teams to design highly specialized Slack-driven workflows that reflect their internal processes. Example: Triggering a Custom Workflow 
  {
    "type": "actions",
    "elements": [
      {
        "type": "button",
        "style": "primary",
        "text": {
          "type": "plain_text",
          "emoji": true,
          "text": "Show Incomplete Action Items"
        },
        "value": "incident-list-out-incomplete-action-items",
        "action_id": "trigger_custom_workflow"
      }
    ]
  }

​
Attachments

Attach secondary content to your main message. Use this for content that adds further context or additional information but isn’t vital. Please note attachments are a legacy part of the Slack messaging functionality. You should understand that they might change in the future, in ways that reduce their visibility or utility. See Slack documentation for more details.

​
Troubleshooting

  • Confirm the workflow ran successfully
    Check the workflow run history in Rootly to ensure the action was executed and did not fail validation.
  • Verify channels and recipients
    Ensure the Channels field is set (for example, {{ incident.slack_channel_id }} or a valid #channel name) and that the Slack app has access to that channel.
  • Check Slack app permissions
    Confirm that the Rootly Slack app is installed in the workspace and added to the target channels.
  • Validate required targeting
    For ephemeral messages, you must specify Slack Users or Slack User Groups and Channels.
  • Confirm channel membership
    The targeted users must be members of the specified channels; Slack will silently drop ephemeral messages for non-members.
  • Test with a direct tag
    Try sending an ephemeral block to a single known user and channel to isolate whether the issue is configuration or targeting.
  • Use Block Kit Builder for structure
    Copy the JSON (without Liquid) into Slack’s Block Kit Builder to validate structure and layout.
  • Add Liquid cautiously
    After validation, reintroduce Liquid variables in Rootly. If a block suddenly fails, temporarily remove or simplify Liquid expressions to identify the culprit.
  • Avoid unsupported elements
    Ensure you are only using Block Kit components that are supported in the surfaces where the message will appear.
  • Verify action_id values
    Confirm that the action_id matches a supported Rootly action (for example, toolbar_update_status, manage_form_field_selections, trigger_custom_workflow).
  • Check integration prerequisites
    Responder-related actions (such as pagerduty_responders, opsgenie_responders, victor_ops_responders) require the corresponding integration to be installed and configured.
  • Confirm permissions
    Some modals (like status updates or role management) require the user to have permission to update the incident. If they do not, the click will not perform the expected action.
  • Confirm the value field
    • For trigger_custom_workflow, the value must equal the workflow’s Slack command (under Advanced Settings).
    • For open_custom_form, the value must equal the custom form’s slug.
  • Check workflow state
    Ensure the targeted workflow is enabled and not restricted by conditions that prevent it from running in this context.
  • Review logs or run history
    If the workflow runs but does not behave as expected, inspect workflow logs for validation errors or unmet conditions.
  • Ensure “Select a Task” points to the correct parent
    If the wrong parent action is selected, messages may thread under an unexpected Rootly message or appear as new root messages.
  • Check “Update Parent Message” vs. “Reply in Thread”
    If you set “Update Parent Message”, no new thread reply will appear; the original message will be replaced.
  • Review “Broadcast Thread Reply to Channel”
    If a reply appears both in thread and as a new root message, this option is enabled; disable it if you only want threaded responses.
  • Verify trigger conditions
    Check that the workflow’s trigger and conditions (severity, type, environment, status, etc.) match the incident state when you expected it to fire.
  • Inspect workflow run history
    Look for failed runs or validation errors related to Slack fields (for example, missing channels, invalid JSON, or failing Liquid).
  • Test with a simplified version
    Temporarily simplify the workflow to a minimal “Send Slack Blocks” step with a static Block Kit payload to confirm that the basic action works, then reintroduce complexity incrementally.