Creating a Content Approval Workflow with n8n and Slack

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 decision

This 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:

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 confirmation

This 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.

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?