What do you do when one Slack request says “VPN is broken,” another says “need Salesforce access before 2 PM,” and a third says “finance export failed again” before lunch? If all three land in the same intake channel, someone on your team becomes the human parser who asks follow-up questions, rewrites the request, picks an owner, and guesses whether the issue can wait. That job gets old fast.
What would change if every requester had to answer those questions before a human ever touched the queue? This tutorial walks you through the intake form, AI step, branch rules, and review loop that turn that messy channel into a cleaner handoff instead of a second queue that still needs manual triage.
Start With The Decision, Not The Form
Slack Workflow Builder and the Generate AI response step can automate the tedious part of request intake, but only after you decide what the workflow is allowed to decide for you. Slack says workers using its AI features save an average of 97 minutes per week. Useful number. But it only matters if those minutes stop disappearing into “Can you give me more detail?” replies and routing mistakes.
Before you touch the form builder, define the four moving parts below. If you skip this step, you are not improving triage. You are collecting vague requests in a new interface without improving how they get classified or routed.
| Workflow Part | Job | What Breaks Without It |
|---|---|---|
| Intake form | Collect the minimum facts | The AI has to guess what the requester meant |
| AI step | Summarize, classify, and test for ambiguity | A human still has to rewrite every request |
| Branch rules | Route by category, priority, and confidence | Everything lands in one channel again |
| Tracking list | Record owner, status, and follow-up | The request vanishes after the first reply |
That model defines the workflow. Next you need the minimum setup that keeps the build tied to real Slack behavior instead of assumptions.
Prerequisites
If you want to follow along hands-on, you’ll need:
-
A Slack workspace where the AI workflow features are available because Slack ties availability to plan and workspace configuration, and you do not want to discover that after you design the flow.
-
Permission to create or edit workflows, lists, and channels because this build uses a form, a list-backed intake, and branch logic in the Slack UI.
-
A few trusted knowledge sources such as a policy canvas, a resolved-request list, or a support channel because grounded AI only helps when the sources already reflect how you want work routed.
-
Two or three destination teams or channels for your first rollout because a narrow workflow is easier to validate than a single intake that tries to classify every request type on day one.
Reality Check: If your form asks only “How can we help?”, the AI is not doing triage. It is doing cleanup on missing context.
Slack is a UI-first tool here. There is no cleaner command-line path for building this workflow, so keep the tutorial focused on the native Workflow Builder, Lists, and branching features that Slack actually exposes.
Build The Intake Layer
Slack’s guide on collecting and triaging requests with Lists is the right starting point because it gives you form submission, a shared queue, assignees, and threaded follow-up in one place.
Choose The Intake Fields
Start with a new list or the help-request template, then add only the fields that improve routing. Every field should help the workflow decide faster, not make the requester fill out a tax form.
Use fields like these:
| Field | Why It Matters |
|---|---|
| Request details | Gives the AI the raw problem statement |
| Affected system | Separates access, app, and platform issues quickly |
| Business impact | Helps distinguish “annoying” from “blocking payroll” |
| Needed by | Exposes time-sensitive work without guessing |
| AI summary | Stores the one-line normalized version of the request |
| AI category | Feeds branch logic and saved views |
| AI confidence | Decides whether to route or ask for clarification |
| Final owner | Shows where the request actually landed |
Turn On Form Automation
After you create the list, open the workflow in Slack’s builder and make sure you are working in the live step catalog, not in a planning document. The screen below is the state to confirm before you continue: the builder is open, and the destinations you may route into are visible in the picker.
Builder step picker
Now turn on form automation and submit one test request. Do not move on until that submission creates a list item with its own thread, because the AI summary and the branch results need to attach to that record later.
Add The AI Step And Ground It
Slack’s AI step can work from channels, canvases, lists, files, and workflow variables. That sounds flexible because it is. It is also how people accidentally ground a routing decision in stale or incomplete reference material. Use sources that answer one question: “Where should this kind of request go, and what details make that decision safe?”
That mapping work is boring, but it determines whether the workflow makes a defensible routing decision or just produces polished text. It is also the kind of business process automation Adam Bertram focuses on: define the inputs, the decision, and the owner before you ask AI to help.
Use a prompt that forces the model to stay inside those boundaries:
“`plain text
You are triaging an internal request submitted in Slack.
Use the request form fields and the attached Slack knowledge sources.
Return:
1. A one-sentence summary of the request
2. A category: Access, App Support, Billing, HR, or Other
3. A priority: Low, Medium, or High
4. A routing recommendation
5. A confidence label: High, Medium, or Low
6. One clarifying question if the request is incomplete or ambiguous
Do not invent facts.
If the request lacks enough detail, say that plainly.
If the request could affect multiple teams, route it to manual review.
“`
Keep the prompt strict, then let the sources provide the nuance. Slack’s AI security guidance says customer data stays inside Slack-controlled infrastructure, is not used to train LLMs, and only uses data the requesting member can access. Good. That protects privacy boundaries. It does not rescue a bad prompt or a weak knowledge base.
The practical rule is simple: ground the model in policy, not in folklore. If your routing logic currently lives in three people’s heads and a half-forgotten thread from last quarter, fix that first.
Route Clean Requests And Catch The Messy Ones
Once the AI step produces structured output, use workflow branches to split the work. This is where you decide which requests can move automatically and which ones must stop for review.
Send Clear Requests Straight Through
A clean request with high confidence should move without ceremony. A vague or risky request should stop and ask for help.
Before you save the branch rules, confirm the condition is reading the workflow variable you expect and that the next step under that condition points to the right destination. The Slack branch-builder view below shows the kind of condition block you should verify before you publish, even if your own workflow name and routes differ.
Branch builder
| Branch Rule | Route | Why |
|---|---|---|
| Category = Access and Confidence = High | IT access queue | These are usually repeatable and policy-driven |
| Category = Billing and Confidence = High | Finance ops queue | Billing requests need the right owner fast |
| Category = HR and Confidence = High | HR requests queue | People issues should not bounce through tech support |
| Confidence = Low | Clarification path | Missing context should block automation |
| Priority = High | Shared triage channel | High-impact work needs a human eye immediately |
| Multiple teams implied | Manual review path | Cross-team requests are where bad routing starts |
The branch layout should make the safe path fast and the uncertain path obvious. If the condition references the wrong field or the wrong button state, the workflow can still publish and then route requests incorrectly.
Warning: “Low confidence” is not an annoying edge case. It is the workflow telling you it does not know enough to make a safe handoff. Treat that as a feature, not a failure.
Stop Ambiguous Requests Early
A good ambiguity rule set looks like this:
-
If the requester did not name the affected system, ask for it.
-
If the AI cannot match the request to a grounded category, route to a human triage channel.
-
If the request mentions financial impact, people data, or urgent outages, bypass auto-routing and send it to manual review.
-
If the request belongs to two teams, do not let the model guess which team will be less annoyed.
That last point is where many AI workflows fail. The draft looks polished, the category sounds plausible, and the wrong team still gets the ticket. Clean language is not the same as a correct routing decision.
Test The Workflow Before You Publish It
Slack’s AI workflow guidance explicitly recommends using the interactive preview before you publish. Use that preview with ugly requests, not only the tidy examples you wrote for yourself during setup.
Before you call the build ready, confirm the published entry point is visible where users will actually start the request. The Slack screen below shows the state you want after publish: a clear Start Workflow action in the destination surface instead of a workflow that only exists in the editor.
Published entry
Run Ugly Test Cases
Run at least these three tests:
| Test Request | Expected Result | What You’re Verifying |
|---|---|---|
| “Need access to Salesforce quotes by 2 PM for a renewal call” | Access category, medium or high priority, IT route | Clean classification and urgency handling |
| “The report is wrong” | Low confidence plus clarifying question | The workflow refuses to guess without context |
| “Payroll export failed after the HR import” | Manual review or shared triage route | Cross-team and high-risk requests do not auto-route |
Inspect The Handoff Output
Then inspect the actual list item and thread output:
-
Does the AI summary make sense to a human who did not read the original submission?
-
Did the confidence label match your own judgment?
-
Did the branch route create the least surprising outcome?
-
Did the clarifying question ask for the missing fact instead of restating the problem in nicer words?
If a test fails, fix the form or the branches before you touch the prompt again. Prompt edits can feel fast. Missing fields and bad routing rules are the usual problem.
Publish It Without Creating Another Support Problem
After the tests pass, publish the workflow and save a few operational views in your list. Slack Lists supports sorting, filtering, grouping, and threaded discussion around each item, so use that to make the queue readable for humans.
Set up these views first:
-
A
Needs Clarificationview filtered to low-confidence items -
A
High Priorityview filtered to urgent work regardless of team -
A per-team view for each destination queue so owners are not scanning the whole intake board
Also send an acknowledgment back to the requester with the AI summary, the current owner, and the next expected action. That reply gives the requester one place to correct a bad assumption before the wrong team spends half an hour on it.
Review the workflow every week for the first month. Count misroutes. Count clarifications. Count items that sat unowned. Those numbers tell you whether the form is missing a field, whether a branch is too broad, or whether a source document drifted away from the real process.
Keep The Handoff Defensible
A Slack intake workflow becomes useful when it does three things well: it gathers the facts before the handoff, it grounds the AI step in real team knowledge, and it sends unclear requests to clarification or manual review instead of auto-routing them. That is the standard to hold.
Build the form first in Slack Workflow Builder. Ground the AI with sources you trust. Branch only when the request is clear enough to move safely. If the workflow cannot defend the route it picked, it should ask a question or hand the work to a human. That is not less automated. That is what responsible automation looks like.
