Slack Workflow Builder forms, variables, branches and triggers

Forms are where Slack workflows become genuinely useful. A form turns a loose request into the same few answers every time. Variables carry those answers into later messages, branches send each request to the right place, and a trigger decides when it all starts. This guide covers all four, with a worked example at the end. For an overview of the builder itself, start with our guide to Slack Workflow Builder.

How the four pieces fit together

A trigger starts the workflow, such as someone clicking a link or a schedule firing. A form step collects answers. Variables carry those answers forward, because any information submitted to your workflow can be referenced in later steps. A branch then routes the workflow based on an answer.

You need a paid plan for any of this, since anyone on a paid subscription can create workflows by default. Branches have a stricter requirement, covered below.

Forms

Add a form step

In Workflow Builder, add a step and choose Collect info in a form. Give the form a title people will recognise, then click Add Question for each thing you need to know. Each question can be short text, long text, a date, a person or a select list of options you define. Mark only the essential questions as required.

When the workflow runs, the person who started it fills in the form inside Slack. A later step can then post the answers. A typical message mentions the person who filled out the form and includes their response, so whoever reads it has the full context.

Form answers are also saved. Workflow managers can download workflow form responses to sort and count them, and connector steps can send each response to a spreadsheet as it arrives. Slack's own tips show forms that add responses to a Google Sheet automatically.

Design questions people will answer

Every extra question lowers the chance someone uses the form instead of posting a loose message. Three or four questions is plenty for most requests.

Whenever an answer decides where a request goes, make that question a select list, not free text. A branch can match "Billing" every time; it cannot match "it's about an invoice I think." Short, distinct options also make the results easier to count later.

Ask the most important question first. If people abandon a form halfway, you still get the part that matters.

Variables

Variables are how a workflow remembers. Each answer in a form becomes a variable, and so does information about the workflow itself, such as who started it. Slack notes that the @mention of the person who started the workflow can be added as a variable to a message the workflow sends.

In the builder, you insert a variable wherever you can type a message, usually through an Insert a variable option. The variable appears as a token, and Workflow Builder replaces it with the real answer each time the workflow runs. In this guide, variables are shown in braces:

Send a message to #it-requests  New request from {Person who used this workflow}  Tool: {Which tool?}  Needed by: {By when?}  Reason: {Why do you need it?}

Variables also make confirmations easy. Add a final step that sends a message to {Person who used this workflow}, repeating what they asked for and where it went. People stop asking "did my request go through?" once the workflow tells them.

Two habits keep variables useful. Name form questions clearly, because the question becomes the variable's name in later steps. And put the most important variables first in a message, since many people only read the notification preview.

Branches

Branches send a workflow down different paths depending on what happened earlier. A form answer is the most common condition; Slack's own example is a form whose answers are each assigned to different branches.

Check your plan first. Slack's help center says your workspace must be on the new version of Business+ to use workflow branches. If you do not see the option, that is the likely reason.

To add one, click Add step where the branch should go, then choose Utilities and select Add a branch. Under Only continue if, choose the conditions for that path, give the branch a name if you like, and save. Repeat for each path you need.

Always add a fallback. A fallback is the branch the workflow follows when no other condition is met, so an unexpected answer still goes somewhere instead of nowhere. You can add up to 15 branches to a workflow and nest up to five more beneath a branch, though most useful workflows need two or three.

Triggers

The trigger decides how people meet your form. Workflow Builder offers several, and they suit forms differently.

A link is the usual choice. Sharing the link in Slack shows a Start workflow button, and the form opens when someone clicks it. Bookmark the link in the channel where requests belong.

A schedule cannot open a form for everyone at once, so pair it with a button. A button pauses the workflow until someone clicks, and Slack notes that a button could show a form when clicked. That is how a weekly check-in collects answers.

An emoji trigger suits feedback. Slack's feedback template sends a form when someone reacts to a message with the emoji you choose. A webhook is different again: it starts a workflow from outside Slack and passes data in variables, with no form for a person to fill in.

A worked example from form to the right channel

Here is a support request workflow that uses all four pieces.

Trigger:  From a link (bookmarked in #help)Step 1:   Collect info in a form            What do you need help with?   (long text, required)            What kind of request is it?   (Technical / Billing / Account access, required)            How urgent is it?             (Today / This week)Branch:   If "What kind of request is it?" is "Technical"            Send a message to #help-eng          If "What kind of request is it?" is "Billing"            Send a message to #help-finance          Otherwise (fallback)            Send a message to #help-generalEach message: {Person who used this workflow} needs help: {What do you need help with?} Urgency: {How urgent is it?}

The select list makes the branches reliable, the fallback catches account questions and anything new, and every message carries the variables the reader needs. For more complete outlines like this one, see our Slack workflow examples.

Common mistakes

The most common mistake is asking too much. A seven-question form gets skipped, and the request arrives as a loose message anyway.

The second is branching on free text. If the condition depends on what someone typed, it will fail the first time they phrase it differently. Use options.

The third is publishing without a test run. Before you share the link, run the workflow yourself with one answer for each branch, including one that should land in the fallback. Check that every message arrives in the right channel with every variable filled in. Ten minutes of testing saves a week of confused requests.

The fourth is forgetting permissions. A step that posts to a channel needs posting permission for that channel, so publish only after testing in a private channel. And remember that people from other companies can use workflows in Slack Connect conversations, which makes forms handy in customer channels. Write those questions with the customer in mind.

When a request form is not enough, because you need assignment, status and reporting for every request, a ticketing tool may be the next step. Our guide to Slack ticketing systems explains when that is worth it. For everything else, return to the main Workflow Builder guide.

Questions people ask