Hi everyone. I know we have a lot of community managers and ops folks here, so I'm hoping someone has run into this already.
We've been testing the new Slack workflow builder (the one they're pushing everyone to migrate to) and I'm hitting some consistent friction points. The visual builder is cleaner, but it feels like a step back in flexibility. For example, trying to set up a conditional approval path based on keywords in a request channel seems to require more steps and external webhooks now, where the old system felt more direct.
I'm evaluating this primarily for internal tooling and community moderation workflows. Has anyone else made the switch and found workarounds for these limitations? I'm particularly interested in:
- Handling multi-stage approvals without duplicating workflows.
- Passing data between steps more reliably (we've had issues with variables not populating).
- Any third-party tools or bots that bridge the functionality gap.
I'm happy to share our current configs if it helps. Mostly, I'm looking to see if my team is missing something obvious or if this is a common pain point. The documentation hasn't been super clear.
— Eric
Keep it civil, keep it real.
Switching CRMs every year means I've seen this pattern before. Slack's "new" workflow builder is just the latest round of "we simplified it so hard we broke it."
> it feels like a step back in flexibility
You're not missing something obvious. This is exactly what happens when a tool tries to make a visual builder "accessible" to non-technical users. They strip out the low-level control and tell you to use webhooks for everything. I'd bet the old system had a JSON editor or allowed raw function calls, right? The new one is a parade of dropdowns.
For your concrete problems:
- Multi-stage approvals without duplicating workflows: you can't. I've seen people fake it by using a single workflow that loops back to a step via a webhook trigger, but that's a maintenance nightmare. The alternative is to accept you'll have 5 near-identical workflows and centralize the logic in a database (Airtable or Notion) that you call via Slack's API. That's not a workaround, that's a different architecture.
- Data passing between steps: variables populating inconsistently is a known issue. Slack's documentation is written by people who clearly tested with strings like "hello world" and nothing real. The workaround is to use a middleware like Zapier or Make to reformat the payload before it enters the workflow. Adds latency but at least it works.
- Third-party tools: there's a bot called "Workflow Buddy" (or something similar) that wraps around Slack's API and gives you a visual editor that actually respects variable scoping. Also, Pipedream has a Slack integration that lets you write actual code for each step, which is what I'd recommend if your team has any scripting chops.
The real question is: how much are you willing to invest in something that Slack will probably deprecate in 18 months? They're already talking about "AI-powered workflows" that will abstract away even more control. I'd rather spend the time moving community moderation logic to a dedicated tool like Orbit or Common Room, and just use Slack as the notification layer.
What's the specific keyword-based approval path you're trying to build? I might have a pattern that avoids the worst of the new builder's limitations.
Spot on about the "simplified it so hard we broke it" cycle. The real punchline is the pricing. That "parade of dropdowns" still costs the same per-seat as the old system, while they offload the actual work of connecting it to real logic onto you. So you pay the premium, but you have to build and host the backend they removed.
Calling their own API from webhooks is their standard answer for every missing feature now. It's cost externalization disguised as an upgrade.
Buyer beware.