What Slack Workflow Builder can and cannot build

Someone on your team asks for a thing. A way to submit the request instead of pinging you. A number nobody can agree on, worked out the same way every month. You are already in Slack, so you open Workflow Builder, because it is right there and it does not need a ticket.

Sometimes that is exactly right. Sometimes you find out forty minutes in that the tool cannot do the thing, and it is not obvious beforehand which of those you are in.

Here is the line, and it is not the one people expect.

What Workflow Builder is for

A workflow is a trigger and a sequence of steps. Somebody clicks a button or fills a form or joins a channel, and Slack then does things in order: posts a message, collects fields, waits for an approval, sends the result somewhere. You can add connector steps that reach into a third-party service once you authenticate it.

The detail people underestimate is that by default anyone in the workspace can build one. It is not an admin tool. The person with the problem can usually go and solve it without asking anybody, which is most of why it gets used at all.

It is genuinely good at what it does. New-hire onboarding checklists, PTO requests, incident intake, a form that lands in the right channel with the right fields already filled in. If what you want is to collect some information and move it somewhere, close this tab and go build it. Nothing has to be approved and it will take you an afternoon.

Where it stops

Workflow Builder automates a process. It does not answer a question.

That distinction matters more than difficulty does, which is where most comparisons go wrong. The things people ask for are usually small. They are still outside it.

“Which of our vendors is closest to this job site.” That is a lookup against a list you already hold. One sentence to describe, and there is no way to express it as a trigger and three steps.

“What is my commission this month.” A calculation, and not a hard one. Workflow Builder can collect the inputs and route them to the person who works it out. It cannot work it out.

“Show me the renewals I own so I can sort them.” A screen somebody opens again next Thursday. A form is not an interface, and a message is not a report.

None of those are ambitious. They are just not processes, and a process is the only shape Workflow Builder knows how to model.

The custom step escape hatch, and what it costs

Slack’s answer to all of the above is custom steps: you can extend Workflow Builder with your own step and then use it like any other.

It is worth reading what that involves before you treat it as an option. You create a Slack app, wire up a bot token and an app token, run a development server, and implement a function listener that Slack calls when your step is invoked. Then you need somewhere for that app to live so it is still answering next month.

That is a developer project with a deploy story and an owner. Which is roughly the problem you opened Workflow Builder to avoid.

Your admins can also restrict which custom steps people are allowed to add, so on a managed workspace the route may be closed before you start.

The test

If you can say it as “when this happens, do that, then send it there,” it is a workflow. Build it in Workflow Builder and stop reading.

If you catch yourself inventing steps to fake something that is really just a question with an answer, steps are not going to get you there. You want a small app, and that has always been the point where a simple ask turns into a project nobody has time for.

What we are adding

Sploot now takes that second kind of ask in Slack. Somebody describes what they need in the channel where they would otherwise have asked a colleague, and a small working thing comes back into the same conversation, with the company sign-in already in front of it and open to the people in that room.

The person asking does not have to be technical, and does not have to model their problem as anything. They ask for the outcome in the words they would have used on a coworker.

We are not trying to turn Slack into a place where software gets built. It would be a poor one, and anyone who wants to sit down and work on the thing properly can point their own agent at our MCP endpoint and stay in the editor they already use. Slack is where the asking happens, so it is where the answer should turn up.

Which also means Workflow Builder is not the enemy here. It can do the intake and hand off to the app perfectly well. The two solve different halves, and the half we care about is the one where the honest answer today is that somebody adds it to a backlog.

Sploot is in private beta and there is nothing to log into yet, so read that as intent rather than an offer. If people keep asking your team for the second kind of thing, get on the list and tell us what you would put up first.