Key Takeaways — brief reading, less than 30 seconds
- Slack is built for conversation, which is the opposite shape of an approval audit trail. The mismatch is the whole problem.
- Four reliable failure modes: thread scrolls away, thumbs-up ambiguity, wrong-version approval, retention deletion.
- Slack is excellent for notifications and bad for record-keeping. Use it for what it’s good at; don’t make it the system of record.
- Approvals are structured events (state, actor, timestamp, target version). Slack threads have none of those structurally.
- In-Slack approval apps (Workflow Builder, Approval Donkey, Workato-routed) make Slack approval less broken, not correct. The approval still lives in the integration tool, not on the asset.
- The hybrid: Slack webhooks for notifications, DAM for the approval record. Six months later, “who approved this?” has a one-click answer.
Glossary8 terms
- Approval workflow: The sequence of steps an asset moves through to reach a recorded sign-off — submission, review, comments, decision, and a durable stamp tied to a specific version.
- Sign-off: A binding decision (approved / rejected / needs changes) attributed to a named reviewer at a known time, attached to one specific version of the asset.
- Version: A frozen snapshot of an asset. Approvals attach to a version, not to a file name, so a later upload doesn’t silently inherit the previous approval.
- Annotation: A reviewer comment pinned to a coordinate on the asset (a point on an image, a frame in a video). Resolves ambiguity that a free-text reply leaves open.
- Markup: Visible drawn or highlighted feedback on the asset itself — arrows, boxes, redlines. Sits alongside annotations and stays attached to the version it was made on.
- Threaded review: A scoped conversation grouped under a single annotation or comment, so a back-and-forth about one issue doesn’t interleave with unrelated feedback.
- Single source of truth: One system where the canonical asset, its versions, and its approval state live. Slack is by design a copy-of-the-conversation; a DAM is by design the original record.
- Ephemeral message: A message in a system where retention is short or scrolling and search make recovery impractical. Slack threads are ephemeral for audit purposes even when technically retained.
Editor's note: This is an opinion piece with a clear position: Slack is the wrong system of record for creative approvals. The hybrid pattern at the end uses Slack for what it’s good at and the DAM for what it’s good at — together, not instead.
Slack is a terrible place to approve creative work, and the reason is structural rather than cultural. An approval is a durable record — a named person, a decision, a timestamp, a specific version of a specific file. A Slack thread is the opposite: a conversation that optimizes for speed, scrolls out of reach, and gets deleted on a retention schedule nobody on the creative team is watching.
When the approval lives in the thread, you have no real audit trail, because a thumbs-up emoji carries no decision and a reply carries no version. Slack was never designed to be the system of record, so when you make it one, the decision and the proof of it don’t survive together.
We wrote about the broader approval process; this article is specifically about why Slack as the venue fails, and the hybrid pattern that lets you keep using Slack without keeping the audit trail there.
Why Approving in Slack Feels Right#
The reasons teams default to Slack are sensible, individually. Slack is where the team already is. Approving in Slack avoids context switching. The reviewer is on Slack three times an hour anyway; the file is a click away; the team’s Slack channel is already named after the project. The path of least resistance is to drop the file and ask “approved?” in the channel.
Slack feels right for the same reason it fails here: it optimizes for low-friction conversation, and conversation is disposable by design. Threads scroll past. Yesterday’s file is gone today, regardless of whether someone said “approved” in it — and whatever got said goes with it.
The Four Failure Modes#
Four reliable ways Slack-as-approval breaks. If your team approves in Slack, you’ve probably hit at least two of these.
- The thread scrolls away. The approval is buried in yesterday’s messages. The PM scrolls back through 200 messages to find “approved.” Three months later, scrolling that far isn’t practical; the approval might as well not exist.
- The :thumbsup: ambiguity. Was that an approval, or was that “I saw this”? Reactions don’t carry intent. The reviewer who clicks the thumbs-up doesn’t know whether they’re saying “ship it” or “received, will review.” Three weeks later, neither does anyone else.
- The wrong-version problem. The file got edited after the approval. The PM uploaded V2 the next day; the approval was on V1. Without version control on the file, nobody knows which version was approved. The most expensive variant of this is when the approval was on V1 but V3 shipped, and V3 had a clause legal would have flagged.
- The audit trail is gone in 90 days. Slack Free hides messages older than 90 days(opens in new tab), and paid plans have retention rules that delete messages by the time the campaign is being audited. The approval evaporates on a calendar nobody on the creative team is watching.
Any single failure costs an afternoon of rework. Multiple failures stacked on a regulated campaign produce a legal incident. The cost lands later, at audit time, when somebody asks who approved what and nobody can prove it.
What Slack Is Actually Good For#
This isn’t a Slack takedown. Slack is excellent at what it was designed for: low-friction team chat, fast status updates and notifications, and real-time collaboration on in-flight work. “Hey, the brief is ready for review.” “Hey, round 2 is up.” “Hey, this is blocked on legal.” Slack is great as the notification layer above an approval system. It’s bad as the approval layer itself.
The argument is about scope of tool, not about Slack’s value. Use Slack for the notifications and feedback it does well; use a different tool for the audit trail it does poorly.
What Approval Should Live On Instead#
The rule: the approval lives on the artefact. Comments on the file, an approval state on the specific version, an “approved by [name] on [date]” stamp attached to the asset — the accountability the thread never had. Slack notifies; the DAM (or the creative review tool) records. The notification can scroll away; the approval cannot.
An approval is an event with structure: a state (approved / rejected / needs changes), an actor (who approved), a timestamp, and a target (which version of which asset). Slack threads have none of those structurally. A reaction emoji has no state machine. A reply has no version target. A timestamp is on the message, not on the artefact. The reason approvals belong in a system designed for them is that approvals are structured data, not conversation. The same is true of creative feedback — it belongs on the version it’s about, not in a thread.
Here’s the pattern in practice. The reviewer opens the asset in the DAM, comments with required changes or clicks “Approve.” The DAM records the approval against the specific version, with the reviewer’s identity and the timestamp. Ask “who approved this?” a year on and the answer is one click away — permanent, attached to the asset, and still there after the team rotates off the project.
What About Slack’s Built-in Approval Apps?#
Slack has automation tooling for approval. None of it solves the underlying problem; some of it makes the problem worse by making the broken pattern feel official. Three categories, and each leaves the record off the asset.
In-Slack approval tooling
- Slack Workflow Builder(opens in new tab)paid Slack plans only, from $7.25/user/mo — routes approvals well: the reviewer gets a structured button instead of a free-text reply. But the button-click stamp lives in Slack’s database, not on the asset, so six months later you’re correlating two systems to find which version was approved.
- Approval Donkey(opens in new tab)free Member tier / $19/mo flat — routes a structured approve/decline request through Slack (via Zapier) and records it in its own panel. Better than free-text approval, but the record still lives separately from the asset, not on it.
- Workato(opens in new tab)quote-only, enterprise and Zapier(opens in new tab)free tier / from $19.99/mo annual — integration platforms that pull an approval into Slack from elsewhere: the workflow tool sends a notification, the user clicks a button, the workflow tool records the action. That’s backwards: the record ends up two systems away from the file it describes.
The framing that helps: these tools make Slack approval less broken. They don’t make it correct. “Correct” is approval-on-the-artefact in a system designed to keep it — the DAM, the review tool, or the approval workflow tool that integrates directly with the asset. The Slack-side tooling is fine for routing notifications; using it as the system of record reproduces the problem in a friendlier shape.
The Working Hybrid#
The fix combines the two: Slack notifications plus a DAM-resident approval record. The team gets pinged in the Slack channel they’re already in; the record lives on the file. Ask who approved it a year on — after Slack has rotated the message out of retention — and the answer is still attached to the asset.
Most of the wiring is mechanical. Configure the DAM (or the review tool) to fire a Slack webhook on each approval event. The notification shows up in the project channel; clicking it deep-links to the file at the approved version. The reviewer who needs to act gets a button in Slack; clicking the button takes them to the asset and records the approval there. The approval data lives in the system of record forever; the notification scrolls away in days. The part that isn’t mechanical is identity: the Slack user who clicks has to map to the reviewer the DAM records, or the stamp gets attributed to the integration instead of the person who signed off. Sort that out before you trust the trail.
The implementation is small: one webhook on the DAM side, one channel-routing rule on the Slack side, one update to the team’s working agreement that says “approvals don’t happen in Slack threads.” The cultural change is the hard part; the technical change is straightforward. The awkward conversation is usually with one person: the senior creative who’s been approving in Slack for three years and wants to keep approving in Slack. The cost of letting that one person continue is the audit trail of every campaign they touch.
The role that designs this workflow is the Creative Operations Manager. Setting up the webhook and the working agreement is a one-week project. After it, the first time the legal team asks who approved a controversial claim, the answer is one click instead of a day of scrollback. Teams without an ops manager often default back to Slack approvals because nobody owns the working agreement; teams with an ops manager have an obvious owner for “here’s how we approve things, and here’s why we don’t do it in Slack.”
Slack stores everything as chat, and an approval needs structure that chat can’t hold. No amount of bot tooling fixes that mismatch; it just makes it tidier. The hybrid works because it stops asking Slack to be the thing it isn’t: Slack carries the ping, the DAM keeps the record. When somebody asks who approved the discounted-pricing claim, the answer is one click on the asset, not an afternoon of scrollback.
“Where the team already is” and “where the audit trail lives” are different questions with different answers. The working agreement — approvals happen on the artefact, Slack notifies — is the cheapest change a creative team can make this quarter. If your team is still thumbs-upping in a channel, the next campaign is a good time to stop.
Frequently Asked Questions #
Why is Slack bad for approvals?
Email vs dedicated tool — which is worse?
How do you migrate a team off Slack approvals?
What does a good approval workflow look like?
Doesn’t Slack threading solve this?
What about Slack Workflow Builder or approval apps like Approval Donkey?
