Slack Workflows: Requests, Approvals, Alerts
One command, one reaction or one message in a named channel opens a case in your target system – everything else in the channel stays a conversation. Progress comes back as a reply on the same thread, while the case itself is run in your CRM or service desk.
A channel is a conversation, not an inbox
Slack is quick because nothing stands in the way: one field, one line, sent. That is why leave requests, fault reports and approvals pile up in channels never built to hold them. A channel is a stream, not a register: a message is read or unread, never open or closed, and it carries no reference, no owner and no date it is due. The “yes, go ahead” typed on a Tuesday settles the matter in the room – three weeks on, when the office asks who signed off the €4,000, it is one line in a thread nobody can surface again.
The hard part is not connecting Slack to anything. The interface has been stable for years, and a flow that fires on every message is an afternoon's work. The difficulty is the opposite: deciding which messages must deliberately do nothing. “Please approve the pump” and “we should agree who approves pumps” use the same words, and a trigger that swallows both files requests nobody made. After the third phantom approval, the team goes back to typing at each other.
So the first piece of work is a map of your channels, not a workflow: which ones the app listens to, which stay a conversation, what counts as a trigger – a slash command, a reaction from a named role, a message at channel level – and what is meant to stay quiet. Slack is then the way in and the way people hear about it. The case is raised in the business system, where it picks up what a chat message never has: a reference, an owner and a deadline.
What can be started from a channel
We begin with the matter that turns up in the channel most often. Further triggers later share the same app, the same channel map and the same target system.
Approvals with a value threshold
The usual place to start: the request is raised in the channel, the responsible role approves it, and above whatever figure you set, the flow asks for a second signature.
Requests through a short dialogue
Leave, a spare part, access to a system: the command opens a small window with required fields, so the detail that always gets chased later is captured at the start.
Alerts from business systems
Not every alert into the channel – the overdue invoice to the person who owns it, with two buttons underneath: “mine” and “pass to the office”.
Faults and the on-call rota
Who is on call comes out of the rota, not somebody's memory – including at six on a Saturday, when nobody else is reading the channel.
Details from the channel into the system
Enquiries, contact details, meter readings: captured as fields, they land in the CRM or the list instead of being findable only by search.
Shared channels with customers
External people post in shared channels too. Triggers there apply to your own staff only; anyone else gets a reply, not a case.
Which message triggers what
An extract from a channel and trigger map of the kind we write with you: the channels and their listening state on the left, the rules for each on the right, and below them two messages from the same thread.
Five channels in the workspace
- sales-enquirieslistening
- approvalslistening
- service-faultslistening
- client-meyer-buildinternal only
- team-generalnot listening
The app only sits in the channels it needs. In #team-general the word “approve” may come up as often as anyone likes – nothing happens there.
Trigger and effect
| Channel and trigger | What the flow does | State |
|---|---|---|
| #sales-enquiriesMessage at channel level | Create the enquiry in the CRM, post the reference in the thread | runs |
| #approvalsCommand /approval | Short dialogue for amount, cost centre, reason; create the request | runs |
| #approvalsReaction :approved: from the team lead | Write the approval into the case with name and timestamp | runs |
| #approvalsRequest above €5,000 | Ask for a second approval, the order stays blocked | person |
| #service-faultsCommand /fault | Create the ticket and mention whoever is on call | runs |
| #client-meyer-buildMessage from an external guest | No case, reply pointing to the service form instead | no trigger |
Triggers · #approvals
Sandra Kley 09:12
Calls /approval and fills in the short dialogue: €640, cost centre 4200, reason “hydraulic pump, supplier Meyer”.
APR-118 created · waiting for :approved: from @lead-technical · reminder tomorrow 09:00.
Deliberately triggers nothing · reply in the APR-118 thread
Tom Brenner 09:20
“We should approve the second pump at the same time, otherwise we will be stuck again next week.”
No second request. The trigger only applies to the first message of a thread, replies belong to APR-118. Anyone who really wants a second request calls /approval again.
runs througha person takes overdeliberately no trigger
Both messages above use the word “approve” – one raises a request, the other does not. Drawing that line is the work in a Slack workflow; connecting the target system is the easy part.
The channel names, references and the €5,000 limit are an example from a trades business, not a standard we impose – your thresholds, roles and deadlines get set in the intro call. Slack reports who applied which reaction and when; we write both into the case, not only into the channel.
From the message to a documented case
-
Map the channels and the triggers
We walk your channel list with you and note which ones listen and which stay a conversation. Each trigger gets its opposite case: which message uses the same words and must still start nothing?
-
Collect the details instead of guessing
The command opens a short dialogue – amount, cost centre and deadline become fields, free text stays for the description. Where something is missing, the flow asks on the thread rather than filing half a case.
-
Raise the case in the target system
The record is written in the CRM, the service desk or your list, with the sender, the timestamp and the wording that set it off. The Slack message ID stays attached, so the same command fired twice produces one case.
-
Report back on the thread
Reference, owner and next step appear as a reply beneath the original message. Each change of status edits that one reply instead of posting again, so the channel does not fill with notifications.
-
Chase, hand on, record
The flow chases an open approval once your deadline passes, then hands it to whichever second role you nominate. Who decided what, and when, goes into the case with a name and a time – not the channel.
What changes day to day
Today
- “Can someone approve this?” – and then nothing
- Whoever agreed is somewhere in yesterday's thread
- Requests arrive as prose with three details missing
- Alerts go to everyone, so nobody reads them at all
- Somebody has to ask, because nobody writes it down
With a trigger map
- An approval is one reaction, with a name and a time
- The decision sits in the case, not in the chat log
- The dialogue collects the required fields up front
- Alerts reach the role that owns them, not the channel
- The status sits on the thread and keeps itself current
What Slack should not be asked to do
A channel makes a good front door and a poor archive. Four things we settle before quoting:
- Slack is neither evidence nor a file. Messages can be edited and deleted without trace, and how far the history reaches back follows your plan, not your retention obligations. If you have no business system holding a record and its history, and the channel is meant to stay the filing cabinet, that system is the thing to buy first – automating on top of nothing is premature.
- A trigger matches a rule; it does not read intent. The same words turn up in the request and in the sentence discussing it, so we cut the rules narrowly and would rather miss a case than invent one. That has a price: anyone who types their request instead of using the command gets no case at all – and goes on believing they have filed it.
- If your people do not already have Slack open all day, do not buy this. Where half the workforce looks at it once a day, or where things still arrive by phone and across the yard, this only moves the problem to a place nobody watches. A form or a shared mailbox is then the more honest front door – and you will hear that from us in the intro call, not after it.
- The channel map goes stale, and it does so silently. Teams spin up new channels as they please, while the app sits only in the ones that were agreed. Post a request into a new channel and you get no warning – you get nothing, and you find out when you chase it. Someone on your side has to keep that map current, permanently.
Fits your workspace
Scope and price
The entry price covers one trigger type in one channel with one target system, including the reply in the thread. What moves the price, we say before the quote.
- Channel and trigger map, written down and agreed with you
- One Slack app in your workspace, permissions in plain words
- One trigger type: a command dialogue or a role's reaction
- One target system connected: CRM, service desk, ERP or list
- A threaded reply that keeps pace with the status
- Chasing for open cases, handover to a second role
- Documentation, a handover session and 30 days of support
What increases the price
- Several channels, each with its own rules and roles
- Approvals in stages, with value limits and deputy cover
- An ERP or trade-specific system instead of a simple list
- A return path: status changes pushed from the system into Slack
- Shared channels with clients or suppliers over Slack Connect
Several channels with their own roles, staged approvals and a return path from the ERP typically land in the range of our Workflow Advanced package from €2,490. We quote the binding fixed price after the intro call.
All prices excl. VAT · operation and further development optionally via a support package
What you get
-
A working route from channel to case
Built and signed off in a test channel with real triggers, not a demo
-
The channel and trigger map
Which channel listens, what sets it off and what is meant not to – a document your team keeps up without us
-
Permissions and roles, written down
What the app may see, who may approve, who covers for them and what applies while they are away
-
A handover for the channel and the approvers
How to raise a request, when an approval counts and what to do when something fires by mistake
Frequently asked questions about Slack workflows
These solutions fit alongside
Approval Workflows
The approval itself: stages, value thresholds and deputies, wherever the request starts.
Support Tickets in Teams & Planner
The same idea for Microsoft environments: a channel message becomes a case with an owner.
API Integration and Data Synchronisation
Groundwork when the target system has no ready interface.
Automated Status Reports
For when the cases raised in the channel should become an overview outside it.
Which channel should actually be listening?
The intro call costs nothing. We go through your channel list and draft the first trigger map: what opens a case, who may approve it and what stays quiet. By the end you will know whether Slack is your front door – or whether it should not be.
Book a free intro callWhere automated Slack workflows creates value in everyday work
Slack becomes a controlled entry point for requests, notifications and actions while the source of truth remains in the business system.
Three concrete operating scenarios to compare with your own process.Start requests in chat
Structured dialogs capture required data and create the request in the target system.
Send targeted status updates
Only responsible people receive relevant changes and direct actions.
Operate systems from Slack
Approved standard actions can be triggered without bypassing permissions and validation.
A strong fit when …
Systems provide structured data or signals and technical exceptions should escalate with logs, context and clear ownership.
- You handle recurring slack workflow events using repeatable rules.
- The intake, target system and accountable business role can be named clearly.
- Exceptions are allowed to remain visible and move to people deliberately.
Deliberate automation boundary
Sensitive data, binding approvals and permanent records are not stored exclusively in chat.
Explore the technical approach and platformsEstimate time savings with your own volume
The calculator uses 5 minutes today and 1 minutes after automation as fixed example assumptions. It does not replace process analysis.
Illustrative estimate based on the visible assumptions — not a guarantee.