Why Approval Requests Disappear in Email
Email is where approval requests go to wait indefinitely. The mechanism is simple: an approval email arrives in someone's inbox alongside 80 other messages, gets read, doesn't get acted on immediately, slips below the fold, and is forgotten. When the deadline arrives, someone chases it down manually. The workflow stalls multiple times per week on this pattern, and each stall requires a human to notice and intervene.
Slack and Microsoft Teams are meaningfully different from email for time-sensitive task routing — not because they're better communication tools, but because they create different interaction affordances. A Slack message with structured action buttons (Approve / Reject / Need More Info) doesn't require the recipient to open a separate system. The decision is right there in the channel. The friction to act is lower than email, the workflow tool, or any dedicated approval UI they'd have to navigate to. That lower friction translates directly to faster response times on human-gated workflow steps.
The design challenge is making the Slack or Teams integration genuinely useful rather than just a notification mechanism. A message that says "You have a pending approval in [Workflow Tool]. Click here to review." is barely better than email. A message that delivers the complete task context and the action buttons in the message itself is a different category of tool.
What a Well-Designed Approval Message Contains
The content of the approval message is the highest-leverage design decision in a Slack- or Teams-based task routing setup. Get it right and reviewers can act in under 60 seconds. Get it wrong and they bounce to a browser, lose context, and the friction climbs back to near-email levels.
The minimum viable approval message for a business workflow task contains: a clear description of what decision is being requested (not "you have a task" but "approve or reject the contract amendment for Acme Corp — $45K ACV deal, 2-year term"), the key context needed to make the decision (pulled from upstream workflow steps and rendered inline in the message), the decision options as action buttons (Approve / Reject / Escalate / Request Changes), and the SLA — how long before this escalates if not acted on.
For a contract review step, the Slack message might render: the contract's deal value, customer name, and a bulleted list of flagged non-standard clauses from the upstream AI extraction step, with Approve and Request Legal Review as the two action buttons and a note that the SLA is 24 hours. The reviewer reads the message, sees the two flagged clauses, taps "Request Legal Review," and the workflow routes to the legal team. Total time from message arrival to action: 45 seconds. No browser tab opened.
For a shorter decision — a discount approval on a routine deal — the message might be even more compact: deal name, deal size, requested discount percentage, the AI's comparable-deal context ("similar deals at this size averaged 12% discount"), and an Approve/Reject pair with the amount and the rep's name. These high-frequency, low-complexity approvals are where the Slack-native interaction model shows the biggest throughput gains.
Building the Connector: Blocks API vs. Webhook Patterns
Slack and Teams both expose two main integration patterns for workflow-driven task routing: Bot APIs (the full-featured, stateful approach using Slack's Block Kit or Teams' Adaptive Cards) and incoming webhooks (simpler, stateless, limited to sending messages without interactive components).
For task routing with action buttons, the Bot API path is required. Incoming webhooks can't receive user interactions — they only push. The Bot API requires registering an application, handling OAuth for workspace installation, and maintaining a persistent event subscription to receive button-click events and route them back to the workflow. That's non-trivial infrastructure, which is why most operations teams that try to build this from scratch end up with a partial implementation: messages send fine, but the button interactions route inconsistently or require manual webhook handling that breaks on Slack API updates.
The operational pattern that works reliably: the workflow platform handles the Slack Bot API and Teams Bot Framework infrastructure, and the workflow author configures what message to send, what action buttons to include, and what workflow transitions to trigger when each button is clicked. From the workflow author's perspective, the Slack approval step is a node configuration: message template, action options, SLA. From the infrastructure perspective, it's a registered Slack app with a persistent event handler and a state machine callback. Those two perspectives can coexist cleanly when the abstraction boundary is correct — and fail messily when the workflow author has to think about bot tokens and event subscriptions.
Handling the Action Response
When a reviewer clicks Approve in a Slack message, three things need to happen correctly: the workflow state needs to advance, the Slack message needs to update to reflect that the decision was made (so other people who see the message don't think it's still pending), and the decision needs to be logged in the workflow audit trail with the reviewer's identity and timestamp.
The message update is the part that most implementations get wrong. If the message doesn't update after an action is taken, reviewers who look at the message later can't tell whether it's been acted on. This creates double-approvals (two people both click Approve), missed approvals (the review channel shows the original pending message and someone acts on it after the workflow has already advanced), and confusion about workflow state.
Slack's Block Kit supports message updates via the response URL in an action payload — the message can be updated in-place to show "Approved by [Name] at [Timestamp]" without sending a new message. Teams' Adaptive Cards work similarly. For workflows with high message volume in shared channels, this in-place update is important: a channel that fills with dozens of approval messages that never resolve into visible outcomes becomes noise that reviewers learn to ignore.
Cross-Platform and the Single-Queue Problem
Teams that use both Slack and Microsoft Teams — which is common in companies with mixed tool stacks after acquisitions or department-level tool choices — face a routing challenge: some reviewers are in Slack, some are in Teams, and the workflow needs to reach the right person in the right tool. Routing to the wrong platform means the message goes unread.
The routing model that works: the workflow platform stores the preferred messaging channel per user (Slack handle, Teams UPN, or email as a fallback), and the human task node uses that preference to route the notification. If a reviewer has both platforms configured, the primary preference wins. If neither platform is configured, fallback to email with a note that the reviewer should configure their messaging preference.
We're not saying teams should avoid multi-platform message routing — it reflects real organizational complexity. But the routing configuration should be explicit and maintained rather than assumed. A misconfigured routing table that sends Slack messages to Teams users produces the same outcome as no integration at all: the message doesn't reach the reviewer, the SLA timer fires, and the escalation path kicks in. The integration's value comes from message delivery to the right person on the right platform — and that requires maintaining accurate routing configuration as the team changes, tools change, and users move between platforms. An operations checklist that includes "update messaging preferences when onboarding or offboarding team members" is as important to the workflow's reliability as the technical integration itself.