⚡ TL;DR
A real wordpress approval workflow with n8n and Slack should work like this: an AI generates a WordPress draft, n8n sends a Slack message with Approve and Reject buttons using Block Kit, Slack sends the button click back to an interaction endpoint, and n8n either publishes the post or routes it back for revision. That is the grown-up version. Not “AI writes something and somebody notices later.” The useful stack is AI draft creation → Slack approval gate → publish or reject. WordPress already supports saving a post as draft or publish through REST, and Slack interactive payloads already support button-driven actions. n8n is just the orchestration layer that makes all three systems behave like one clean editorial pipeline.
The lazy version of AI publishing is easy: let the model generate a post and dump it straight into production. The problem is that this is also a lovely way to publish mistakes at machine speed.
The better version has one brutally important ingredient: friction. Useful friction. The kind that forces a human to make a decision before the draft goes live. Slack is perfect for that because it is already where editors, marketers, founders, and mildly anxious operations people live all day anyway. If the approval gate happens in Slack, the workflow stops being theoretical and starts becoming operational.
That is why this pattern matters more in 2026 than it did even a year or two ago. AI drafting is no longer the hard part. Governance is. The winner is not the team that generates the most drafts. It is the team that routes them through the cleanest decision system before publishing.
What wordpress approval workflow actually means
A wordpress approval workflow is a system that moves content through controlled editorial states instead of publishing immediately when the draft is created. In this case, WordPress stores the post, n8n handles the orchestration, and Slack becomes the decision interface where a reviewer explicitly approves or rejects the draft before the status changes.
The critical distinction is simple: this is not just content generation. It is state management for publishing.
The short framework
| Step | What happens | Why it matters |
|---|---|---|
| 1 | AI generates a WordPress draft | Creates the content without publishing it prematurely |
| 2 | n8n posts a Slack message with buttons | Puts the decision where the team already works |
| 3 | A reviewer clicks Approve or Reject | Adds a real human checkpoint |
| 4 | Slack sends the interaction payload back to n8n | Turns a button click into workflow logic |
| 5 | n8n publishes or routes the post back | Keeps WordPress in sync with the editorial decision |
That is the version worth building. Not AI autopublishing. AI drafting with a human gate.
Why Slack is the right approval layer
Because approval workflows die when they ask people to log into yet another dashboard.
Slack’s interactive components are built for exactly this kind of decision surface. Its interaction docs make it very clear that interactive components send payloads to a request URL, and those payloads can be used to determine what action the user took. That means your Approve and Reject buttons are not decorative. They are actual workflow inputs.
And yes, Slack also expects the interaction endpoint to acknowledge the request quickly. That matters. If the approval endpoint is slow or sloppy, the reviewer sees an error and your fancy workflow suddenly feels like office comedy.
Why n8n fits this workflow so well
Because this is pure orchestration territory. Webhook in. Draft creation. Slack message out. Interaction webhook back. WordPress status update. Optional notification. Optional rejection loop. That is exactly the kind of multi-step branching workflow n8n handles cleanly.
The important detail from the Webhook docs is that n8n has separate test and production webhook URLs. Use the production URL once this workflow is live. It sounds obvious until someone ships the test URL into the Slack app config and then spends an afternoon wondering why approval clicks vanished into the fog.
The architecture
AI prompt / content source
│
▼
n8n workflow
│
├─ Generate article draft
├─ Create WordPress post with status=draft
├─ Send Slack message with Approve / Reject buttons
▼
Slack channel
│
│ reviewer clicks a button
▼
Slack interaction payload
│
▼
n8n approval webhook
│
├─ Approve → update WordPress post to publish
└─ Reject → update status / notify editor / send revision task
▼
WordPress reflects decisionThis is the clean editorial control plane. WordPress stores the post. Slack carries the decision. n8n connects the two without pretending it is a CMS itself.
How the WordPress draft step should work
The post should be created as a draft, not a published post pretending to wait for approval. WordPress’s REST posts schema already supports draft, publish, pending, and other statuses, so there is no reason to invent weird pseudo-states if the core API already gives you what you need.
A sensible initial payload looks like this:
{
"title": "Creating a Content Approval Workflow with n8n and Slack",
"content": "<p>AI-generated draft content here.</p>",
"status": "draft"
}That is enough to create the editorial object that the reviewer is about to judge. Everything else is just routing logic.
How the Slack message should be built
This is where a lot of tutorials become weirdly unserious. If the Slack message is vague, the approval decision becomes vague too.
The message should include at least the draft title, maybe a short excerpt, a link to preview or edit in WordPress, and two clear buttons: Approve and Reject. Slack’s Block Kit is the right way to do this because the action elements can carry IDs and values that your interaction endpoint can interpret safely.
{
"channel": "C1234567890",
"text": "WordPress draft awaiting approval",
"blocks": [
{
"type": "section",
"text": {
"type": "mrkdwn",
"text": "*New WordPress Draft Ready for Review*\n*Title:* Creating a Content Approval Workflow with n8n and Slack"
}
},
{
"type": "actions",
"elements": [
{
"type": "button",
"text": {
"type": "plain_text",
"text": "Approve"
},
"style": "primary",
"action_id": "approve_post",
"value": "post_id:123"
},
{
"type": "button",
"text": {
"type": "plain_text",
"text": "Reject"
},
"style": "danger",
"action_id": "reject_post",
"value": "post_id:123"
}
]
}
]
}That is the right shape. Explicit. Machine-readable. Not trying to be clever.
How the Slack interaction webhook works
When the reviewer clicks a button, Slack sends an interaction payload to the request URL configured in your Slack app. Slack’s interaction docs are very clear that interactive payloads must be acknowledged quickly, and the payload includes the context needed to figure out which action happened.
That means your n8n approval webhook should do three things immediately:
| Action | Why it matters | What it should do |
|---|---|---|
| Acknowledge fast | Slack expects a quick 200 response | Prevents user-facing errors |
| Parse the button action | The workflow needs to know approve vs reject | Read action_id and post identifier |
| Branch the workflow | The editorial state changes based on the button | Publish, reject, or route for revision |
This is exactly why n8n is a good fit. A branching approval workflow is much more natural in a workflow engine than in a pile of ad hoc scripts.
Approve path vs reject path
The approval branch should be boring. That is a compliment.
Approve means update the WordPress post status from draft to publish. Reject means do something intentional. It could keep the post in draft, add a note to Slack, update a custom field like approval_status=Rejected, or notify the editor that the draft needs revision.
{
"status": "publish"
}That tiny status update is the whole approval event from WordPress’s perspective. Which is nice, because it means the hard part of the workflow is the orchestration, not the CMS write.
Video demonstration: what to record
You asked specifically for a video demonstration, and yes, this is a very good workflow to show on video because the movement between systems is the whole point.
The clean demo sequence should be:
| Scene | What to show | Why it matters |
|---|---|---|
| 1 | n8n workflow generating the article draft | Proves the AI-generated draft is real |
| 2 | WordPress showing the new post in draft status | Confirms the CMS object exists before approval |
| 3 | Slack message arriving with Approve / Reject buttons | Shows the human gate clearly |
| 4 | Click Approve | Demonstrates the interaction event |
| 5 | n8n execution view processing the webhook | Shows the orchestration step |
| 6 | WordPress post changing to published | Completes the loop and proves the automation is real |
That sequence is what makes the workflow feel tangible instead of conceptual. Without it, people nod politely. With it, they understand the system in about thirty seconds.
A clean on-page placeholder for your video looks like this:
▶ Video Demonstration
Record a short screen capture showing the full approval loop: AI draft generation in n8n, draft creation in WordPress, Slack approval buttons, the approval click, and the post status changing to published. Replace this box with your Loom or YouTube embed once the video is ready.
What the n8n workflow should look like
Trigger / AI content source
│
▼
Generate article draft
│
▼
Create WordPress post (status = draft)
│
▼
Send Slack Block Kit message with buttons
│
▼
Wait for Slack interaction webhook
│
┌────┴─────┐
│ │
Approve Reject
│ │
▼ ▼
Update Notify editor / keep draft /
post to set custom approval status
publish
│
▼
Optional Slack confirmationThis is the important thing: the approval decision is not buried in WordPress. It is surfaced where the team already communicates.
What docs do not tell you
The AI draft is the easy part now. The hard part is building a decision layer that does not feel clumsy. That is why Slack approval matters more than people first assume.
Fast acknowledgment is not optional. Slack expects interaction requests to be acknowledged quickly. If you make the webhook wait while doing all the heavy publishing work inline, the reviewer experience gets ugly fast.
Draft-first is not bureaucracy. It is the thing standing between “AI-assisted publishing” and “we accidentally published nonsense at 3:14 PM.”
The approve button should publish only when the draft object is still valid. In real workflows, posts can be edited between draft creation and approval. If you care about rigor, include a timestamp or execution ID so the workflow knows it is approving the right revision.
🛠 Pro-Tip
Store a small immutable token in the Slack button payload, such as post_id + draft_revision_hash. When the Approve button is clicked, verify that the current WordPress draft still matches that revision hash before publishing. That one check prevents reviewers from approving an outdated draft after someone already edited the content in WordPress.
Our experience with wordpress approval workflow design
Our experience with wordpress approval workflow design is that the biggest mistake is focusing too much on generation and not enough on state change. Teams get excited that the AI can write a passable draft. Fine. Useful. But the real operational value comes from deciding what happens next. Who sees it. Where they see it. How they approve it. What happens when they reject it. That is the actual workflow.
We have also found that Slack is unusually effective here because it reduces approval friction without removing approval discipline. People do not need another login. They do not need to visit WordPress just to say yes or no. But the gate still exists, and that gate is what keeps AI drafting from quietly becoming autopublishing.
And honestly, that is probably the uncomfortable question worth leaving on the table: if your team is already using AI to generate WordPress drafts, do you really have an approval workflow yet, or have you just created a faster way to produce content without building an equally serious way to govern it?
