Skip to main content

Get Support
Have a question? Let's get you an answer!

How Do I...? Troubleshooting Code & Webhooks Developer Zone

Other Help Resources
Wait, there's more! Check out these Community sourced spaces for additional resources.

Zapier Help Center Hire an Expert

Learning Resources
All of our best learning resources can be found here.

Featured Articles Show & Tell Asked & Answered Zapier's products AI Hub Zapier Tools Hub

Share your knowledge
Give back to the Community by sharing your automation wins and helping to answer questions.

Share your success See unanswered questions User Groups

Other Learning Resources
Some of our favorite additional ways to upskill your Zapier knowledge.

Zapier Learn Zapier Blog Zapier Webinars

Product Updates
Check out what is new and upcoming with Zapier with our regular product updates.

Product Updates

Early Access Program
Want to join Early Access? Learn more here.

Best answer

Is there a way to create a Zap that gets a Slack reply, then branches based on what the user said?

  • Oct 30, 2026 6:50 PM UTC
  • 4 replies
  • 15 views

Hello there, new to Zapier :) 

I’m trying to see if Zapier will work for some of the use cases I’m working on for my company. We run a lot of work out of Slack, and I’m wondering if a Zap can branch/route mid way through based on text a user replies with in a Slack thread (not buttons I could click, but something that requires AI judgement to match to the next step)? 

 

An example if lead triage, where I get the summary in Slack and reply with some additional account context not in the CRM that it would assess and then route the final actions appropriately. Thank you!

Best answer by WebhookEngineer

I’d use two linked workflows rather than have one Zap wait midway for a reply:

1. Post the lead summary and save the Slack channel/message identifier alongside the lead ID.
2. When a reply comes in, match its parent thread to the lead. Combine the reply with the retained CRM context, then classify it into a small set of allowed routes, including “needs review.”

Before building the routing, I’d test whether Zapier’s Slack trigger captures an actual thread reply and exposes its parent identifier in your channel. I haven’t verified that native coverage. If it doesn’t, a custom Slack event receiver is a fallback to investigate, though that brings extra permissions and maintenance.

Ignore the automation’s own messages and track completed actions so repeated replies don’t repeat a CRM update.

Which final actions would you want the reply to choose between?

View original

4 replies

WebhookEngineer
Forum|alt.badge.img+1

I’d use two linked workflows rather than have one Zap wait midway for a reply:

1. Post the lead summary and save the Slack channel/message identifier alongside the lead ID.
2. When a reply comes in, match its parent thread to the lead. Combine the reply with the retained CRM context, then classify it into a small set of allowed routes, including “needs review.”

Before building the routing, I’d test whether Zapier’s Slack trigger captures an actual thread reply and exposes its parent identifier in your channel. I haven’t verified that native coverage. If it doesn’t, a custom Slack event receiver is a fallback to investigate, though that brings extra permissions and maintenance.

Ignore the automation’s own messages and track completed actions so repeated replies don’t repeat a CRM update.

Which final actions would you want the reply to choose between?

Thanks WE! 

Examples of final actions -- based on account context -- are: draft an email to followup on a topic, update the CRM with missing account data, or adding to a nurture email list. 

Good callout on checking if a thread reply can match the parent message. 

Sorry I think I missed why this would required two Zaps instead of one? Seems cleaner to keep it all in one?

WebhookEngineer
Forum|alt.badge.img+1

You're right to question that. I suggested two Zaps as an event-driven design, not because your three final actions require two.

The lead summary gets posted first, and someone replies later. In the design I proposed, Zap 1 saves the thread-to-lead link and finishes. Zap 2 handles the later reply, using that link to recover the lead context. It's one logical process split across two runs.

Keeping it in one Zap would be cleaner if a native step can wait for that specific free-text thread reply and return its text. I haven't verified that capability, so I shouldn't have implied two Zaps were mandatory. I'd check that first: can the step wait for and return the reply, rather than just delay execution?

With either design, interpreting the reply and choosing email drafting, CRM enrichment, or nurture-list addition comes afterward.

Helpful, thanks!

Early access


Next Gen Zaps

Build and deploy automations from AI tools you already use. With Agentic Management, if anything breaks, the agent diagnoses the issue and proposes a fix.

Request access now


Terms & ConditionsAccessibility statement