How to build a workflow that turns Slack messages into weekly posts (2026)
Turn a week of community Slack chatter into on-brand social posts: pick the channels, read the history with the API, cluster the signal, hold one voice, review, and publish on a weekly cadence.
If your community lives in Slack — a paid community, a team, a customer channel, a Slack Connect space — a week of it holds more publishable material than most creators write from scratch. The wins members post, the questions that keep recurring, the launch someone announced, the sharp one-liner in a thread: each is a post you did not have to invent. The workflow in this guide reads that chatter every week and turns the best of it into finished posts that all sound like one voice, instead of leaving it buried in scrollback.
The shape is a weekly loop, not a real-time firehose. Once a week it pulls the last seven days of messages from the channels you choose, filters the noise down to a handful of post-worthy themes, and drafts posts from them against a fixed voice spec so the output reads as your brand, not as a transcript. It is honest about the two things that make or break this: curation (raw messages are not posts — the signal is a small fraction of the volume) and consent (community members wrote for the room, not for your feed). Get those right and the mechanics are straightforward.
One setup note up front, because it changes what you can build. If you build this as an internal app in your own Slack workspace — the normal case for reading your own community — you get the full message-reading API without the tightened rate limits Slack applied to commercially distributed apps in 2025. Build it for your own room and the read side is generous; build it to resell across other people's workspaces and you are into Marketplace review. This guide assumes the former.
The steps
Decide which channels and which signal feed the digest. Do not point this at every channel. Pick the two or three where publishable substance actually appears — a #wins or #launches channel, a #questions or support channel (recurring questions are content gold), a founder or announcements channel. Then define what counts as signal versus noise: member wins, good questions, product news, sharp takes — not scheduling chatter, emoji-only replies, or internal ops. Write the inclusion rule down; it becomes the filter every later step enforces.
Create a Slack app with read access and invite it to those channels. At api.slack.com/apps create an app in your workspace, then under OAuth & Permissions add the bot-token scopes you need to read history: channels:history for public channels, plus groups:history if you are reading private channels. Install the app to the workspace to mint the bot token, store it as an environment variable, and — this is the step people miss — actually invite the bot into each channel you listed. A bot that is not a member of a channel gets not_in_channel when it tries to read it, not the messages.
Pull the last seven days of messages with conversations.history. For each channel ID, call the conversations.history Web API method with an oldest timestamp of seven days ago and a latest of now (Slack timestamps are Unix epoch seconds with a microsecond suffix, e.g. 1704067200.000100). The response is paginated with a cursor, so loop on response_metadata.next_cursor until it is empty — one call does not return a whole busy week. Pull thread replies for messages that spawned them via conversations.replies, and keep each message's reaction and reply counts: they are your built-in popularity signal for the ranking step.
Filter, dedupe, and cluster the raw messages into themes. This is the curation layer, and it is what separates a useful workflow from a spam generator. Drop bot and system messages, anything failing your inclusion rule, and near-duplicates. Group what remains into a handful of themes — three people asking variants of the same question become one "here is the answer" post; five wins become one round-up. Rank themes by signal (reactions, reply depth, how many distinct members touched it) and take only the top few. A week rarely yields more than three to six posts worth publishing; forcing more produces filler.
Write a voice spec so every post sounds like one person. The messages you are drafting from were written by dozens of different people in dozens of different registers. Without a fixed voice document the output inherits that inconsistency on top of the model's default tone, and the feed reads as a patchwork. Write the spec once: who the account is, sentence rhythm, banned words and phrases, required structures, and three to five reference posts that nail the voice. Every generation call references it. This single document is what makes a Slack-sourced feed sound like a brand instead of a group chat.
Generate the posts from the clustered themes, per platform. Feed each theme — plus the voice spec — to an LLM (Claude- or GPT-class) and draft the post. Generate per platform, not one caption for all: a LinkedIn take reads differently than an X post, and you truncate to each ceiling at a word boundary (X 280, Bluesky 300, Threads 500). Always paraphrase into your own words rather than pasting a member's message verbatim — you want the insight, not the quote — and strip names, handles, and any identifying detail unless you have explicit permission to attribute.
Route drafts through a review gate before anything publishes. Never wire Slack straight to published. Land the week's drafts in an approval queue, read each one against the source thread, and approve, edit, or kill it. This gate is doing double duty here: it catches off-brand drafts and it is your consent-and-privacy checkpoint — the last place to catch a post that reveals something a member said in confidence. Feed every edit back into the voice spec so next week's drafts need less fixing.
Schedule the batch and automate the weekly trigger. Approved posts go into a scheduler, staggered across the coming week at each platform's native cadence rather than dumped at once. Then automate the trigger itself: a weekly cron job (or a scheduled Workflow Builder run, or an n8n/Make schedule) that kicks off the read-cluster-generate steps every Monday morning so the drafts are waiting for your review by the time you sit down. The loop now runs on rails — you spend ten minutes approving, not an hour hunting scrollback.
Common gotchas
Treating raw messages as posts. The publishable signal is a small fraction of a week's volume — without the filter-and-cluster step you generate noise at scale. Curation is the workflow, not an optional polish.
Publishing what members said without consent. People post in a community expecting a room, not a public feed. Paraphrase into your own words, strip names and identifying detail, and get explicit permission before attributing or quoting anyone.
Forgetting to invite the bot to each channel. conversations.history returns not_in_channel for any channel the app is not a member of — being installed to the workspace is not enough.
Not paginating the read. One conversations.history call returns a page, not the whole week. Loop on the next_cursor or you silently miss most of a busy channel.
Reading a private channel with only channels:history. Private channels need groups:history; DMs and group DMs need im:history / mpim:history. Match the scope to the conversation type or the call fails.
No voice spec. Drafting from dozens of members' words with no fixed voice document produces a feed that reads as a patchwork. Write the spec first and reference it on every call.
Building it as a distributed app to resell. Since May 2025 Slack throttles conversations.history to 15 messages per request at one request per minute for non-Marketplace commercially distributed apps. An internal app in your own workspace is exempt — build it there for your own community.
Legal note
Community messages are other people's words, often shared in a space they consider private. Reading them with the Slack API for a workspace you administer is within Slack's terms, but republishing them is a separate question of consent and privacy, not just API access. Before a Slack-sourced post ships: paraphrase rather than quote verbatim, remove names, handles, and identifying details unless you have explicit permission to attribute, never surface anything from a private or DM channel that the person would not expect to see public, and check your own community guidelines or terms for what members agreed to. When in doubt, ask the member. The review gate is where this check belongs — treat it as mandatory, not optional.
Where Kompozy fits
Kompozy treats Slack as a source that feeds the engine, then does the two hardest parts of this workflow for you: holding one voice and shipping the result everywhere. Wire your weekly digest in — a Custom Webhook input or an inbox the engine reads — and each Monday's curated themes land as source material. From there the parts this guide tells you to build by hand are already the product. The voice spec you would write and re-reference on every call is the Persona Brief plus banned-word filters, applied to every generation automatically, so a feed sourced from dozens of members' messages comes out sounding like one account. Each theme can become more than a text post: a carousel of the week's member wins, a quote graphic of the sharpest take, a Persona Short of your avatar answering the question that kept coming up, a blog or newsletter that digests the whole week — 18 formats off the same clustered input, not one caption.
The governance you cannot skip on community-sourced content is built in where it matters. Every draft lands in a per-post review pipeline before anything publishes — that is exactly the consent-and-privacy checkpoint this guide insists on, the place you confirm a post paraphrases rather than exposes what a member said. Approve, edit, or kill each one; approved posts fan out to the 9 social platforms plus email and blog on a scheduled cadence, with per-platform limits and retries handled, and generation runs on durable workers so a closed tab never orphans a job. Honest framing: if you are comfortable calling conversations.history yourself and maintaining the storage, retries, and per-platform APIs, build it — this guide is the blueprint and the control is real. Kompozy is for the creator who wants the read-to-published loop without owning that plumbing: Creator ($49/mo, 2,500 credits) runs a single community's weekly digest for a solo creator; Pro ($299/mo, 18,000 credits) covers multiple communities and higher volume with autopilot; Enterprise is custom for agencies running many brands' communities at once.
Frequently asked questions
Can I read my Slack community's messages with the API?
Yes. Create a Slack app in your workspace, grant it the channels:history scope (and groups:history for private channels), install it, and invite the bot to the channels you want to read. Then call conversations.history with a time window to pull messages. For a workspace you administer this is within Slack's terms; republishing what you read is a separate consent question.
How do I get only the last week's messages?
Pass conversations.history an oldest timestamp of seven days ago and a latest of now. Slack timestamps are Unix epoch seconds with a microsecond suffix. The result is paginated, so loop on response_metadata.next_cursor until it is empty — a single call returns a page, not the full week of a busy channel.
How do I keep the posts sounding consistent when they come from many people?
Write a voice spec — who the account is, sentence rhythm, banned words, required structures, and a few reference posts — and reference it on every generation call. The source messages are in dozens of registers; the spec is what collapses them into one recognizable brand voice instead of a patchwork.
Is it OK to turn what community members post into public content?
Only with care. Members wrote for the room, not your feed. Paraphrase into your own words, strip names and identifying details, never surface private-channel or DM content publicly, and get explicit permission before attributing or quoting anyone. Bake this check into your review step and, when unsure, ask the member first.
Can Slack Workflow Builder do this on its own?
No. Workflow Builder can schedule a recurring run and route messages, but it does not read a week of channel history, cluster it into themes, or generate on-brand posts. Those steps need the Web API plus a generation layer. Workflow Builder (or any scheduler) is useful only as the weekly trigger that kicks the real workflow off.
How many posts should one week of Slack realistically produce?
Usually three to six worth publishing. The publishable signal is a small share of total volume, and forcing more than the week actually contained produces filler that dilutes the feed. Take the top-ranked themes by reactions and reply depth and stop there.