---
title: Purple Workflows: Managing Article Status & Assignee
slug: editorial/purple-workflows-managing-article-status-and-assignee
docTags: 
createdAt: 2026-08-10T13:35:37.192Z
---

Purple Workflows lets your editorial team track an article's progress and ownership without leaving the editor. Instead of switching to a spreadsheet or a separate workflow tool, writers and editors can change an article's status and hand it off to a colleague right from the sidebar — and everyone downstream (including your own systems, via a webhook) is notified automatically.

Purple Workflows is the successor to the Oasis workflow plugin. The two cannot be active on the same site at the same time.

## Key concepts

- **Status** — a step in your editorial process (e.g. *Draft*, *In Review*, *Ready for Print*, *Published*). Beyond the Hub's built-in Draft/Scheduled/Published states, you define your own intermediate statuses to match your team's process, per post type.
- **Assignee** — the person currently responsible for the article. It defaults to whoever last edited the article, but can be handed off to someone else at any time.

## Enabling Purple Workflows

Purple Workflows is rolled out per site by your Purple account team. If you'd like to start using it, get in touch with support — once it's turned on for your site, **Purple Workflows** needs to be enabled (done by your Purple account team).

## Setting up your workflow statuses

![](https://api.archbee.com/api/optimize/ygR6KtT9QI_R0u3uKTJsm/7OiS9yt4TaKjRc-Fol78x_bildschirmfoto-2026-08-10-um-153722.png)

Once enabled, a new **Purple Workflows** menu appears in the admin sidebar, with an **Article Statuses** page underneath it (requires the `Manage options` permission, i.e. Administrator).

On this page you can:

- Add, rename, reorder, or remove statuses.
- Restrict a status to specific post types.
- Attach a **webhook URL** to a status, so your own systems are notified whenever an article is moved into it (see [Webhook notifications](#) below).

Three statuses are always available and can't be renamed or removed, since they map to the Hub's own states:

| Status    | Notes                                                          |
| --------- | -------------------------------------------------------------- |
| Draft     | Regular Hub draft                                              |
| Scheduled | Set via the Hub's own Schedule action, not the status dropdown |
| Published | Set via the Hub's own Publish action, not the status dropdown  |

Everything else — e.g. *In Review*, *Approved*, *Ready for Print* — is entirely up to you to define to match your own editorial process.

## Using it in the editor

::Image[]{src="https://api.archbee.com/api/optimize/ygR6KtT9QI_R0u3uKTJsm/CnW9nhHERMuRHb04cXKFg_bildschirmfoto-2026-08-10-um-153909.png" size="50" isUploading="false" position="center" width="731" height="261" darkWidth="731" darkHeight="261" showCaption="false"}

### Changing the status

In the editor, the usual status row is replaced by a **status button** showing the article's current status (e.g. *2. In Review*). Clicking it opens a dropdown listing every configured status.

- **Scheduled** and **Published** are shown greyed out in this dropdown — those are handled by the Hub's own Publish/Schedule flow, not by picking them here.
- Picking any other status opens an **Update Workflow** dialog where you confirm:
  - **New status**
  - **Assignee** — defaults to yourself, but you can hand the article to any other user who can edit posts.
- If the article is currently scheduled or published, the dialog warns you about the consequences before you continue (e.g. moving a published article back to Draft also unpublishes it; other status changes leave it published).

While the article is saving, or while a scheduled background-publish is in progress, the status button is temporarily locked.

### The assignee

Directly below the status row in the editor sidebar, you'll find an **Assignee** row (labelled **Zugewiesen** in German) showing who's currently responsible for the article. Click it to reassign the article to anyone with edit access, or to clear it back to *Not Assigned*.

You don't have to do anything to keep the assignee up to date day-to-day: **whoever last saved the article automatically becomes the assignee**, unless someone has been assigned to it on purpose (via the status dialog or the sidebar control). Once a deliberate assignment has been made, the article "sticks" with that person and won't silently reassign itself to the next person who happens to save it.

## Finding articles by status and assignee

The **Post Overview** screen gains an **Assignee** column and a matching filter, so you can quickly answer "what's on my plate" or "what's unassigned":

- Filter by one or more specific people, or by **Not Assigned**.
- The Assignee column shows the current assignee's name, or *Not Assigned*.

## Webhook notifications

If you've attached a webhook URL to a status, Purple Workflows sends an HTTP POST request whenever an article transitions into that status — whether the change came from the editor UI or anywhere else in the Hub.

```json
{
  "event": "status_changed",
  "occurredAt": "2026-08-10T09:41:12Z",
  "site": { "url": "https://example.com", "name": "Example Site" },
  "post": { "id": 123, "type": "post", "title": "Article title", "contentId": "...", "editLink": "https://example.com/wp-admin/post.php?post=123&action=edit" },
  "status": { "from": "draft", "to": "in-review", "label": "In Review" },
  "assignee": { "id": 5, "name": "Jane Doe", "avatarUrl": "https://..." },
  "changedBy": { "id": 5, "name": "Jane Doe", "avatarUrl": "https://..." }
}
```

Notes on delivery:

- `assignee` and `changedBy` may be `null` if no one is assigned, or the change wasn't made by a logged-in user.
- The assignee in the payload always reflects the value *after* the change, even if the same request also updated the assignee.
- Delivery happens a moment after saving (it's queued, not sent inline), so saving an article is never slowed down by a webhook endpoint that's slow to respond. There's no automatic retry if your endpoint is unreachable.
- Bulk actions (e.g. bulk-editing many articles at once in Post Overview) don't trigger a webhook per article.

## Permissions

- **Changing an article's status or assignee** requires the same permission as editing that article (`edit_post`).
- **Anyone who can edit posts** can be selected as an assignee.
- **Configuring statuses** on the Article Statuses page requires Administrator access (`manage_options`).

Purple Workflows doesn't introduce its own roles — access is controlled entirely through your existing user roles and capabilities.