Approval Workflow

Wrytze includes a built-in approval workflow that ensures every blog post is reviewed before it reaches your audience. This page covers the post lifecycle, review process, and role-based permissions.

Post lifecycle

Every blog post moves through a defined set of statuses:

Draft  -->  In Review  -->  Approved  -->  Scheduled  -->  Published
                 |                              |
                 \--- Request Changes (back to Draft)

Status	Meaning
Draft	The post is being written or edited. Only the author and admins can see it.
In Review	The post has been submitted for review. A reviewer is assigned.
Approved	The reviewer has approved the post. It is ready for publishing or scheduling.
Scheduled	The post is approved and scheduled for automatic publication at a future date.
Published	The post is live and accessible via the Blog API.

Submitting for review

When an editor finishes writing or editing a post, they submit it for review. Submitting a post:

Changes the status from Draft to In Review
Assigns a reviewer (selected by the submitter or auto-assigned based on team settings)
Sends a notification to the assigned reviewer

Only posts in Draft status can be submitted for review. If a post has already been submitted, it must be returned to Draft (via "Request Changes") before it can be re-submitted.

Review process

Once a post is in review, the assigned reviewer reads the content and takes one of two actions:

Approve

Approving a post moves it to Approved status. The post is now ready to be published immediately or scheduled for a future date. The author is notified that their post has been approved.

If the post needs revisions, the reviewer selects "Request Changes" and provides feedback in a comment. The post returns to Draft status, and the author is notified with the reviewer's comments. The author can then make edits and re-submit when ready.

Comments

Each review includes thread-based comments for discussion between the author and reviewer. Comments support:

Review feedback -- The reviewer explains what needs to change and why
Author responses -- The author can reply to clarify or confirm changes
Discussion threads -- Multiple rounds of back-and-forth before the next submission

Comments are preserved across review cycles, so the full history of feedback is always available.

Role-based access

Not every team member can perform every action. Permissions are tied to the user's role within the organization:

Role	Can Create	Can Submit	Can Review	Can Approve	Can Publish
Owner	Yes	Yes	Yes	Yes	Yes
Admin	Yes	Yes	Yes	Yes	Yes
Editor	Yes	Yes	No	No	Yes
Reviewer	No	No	Yes	Yes	No
Viewer	No	No	No	No	No

Key points:

Editors can create and submit posts, and publish approved posts, but cannot review or approve their own (or others') work. This enforces separation between creation and approval.
Reviewers are dedicated review roles. They can review and approve posts but cannot create or publish content.
Owners and Admins have full access to all workflow actions.
Viewers have read-only access and cannot participate in the workflow.

The separation between Editor and Reviewer roles enforces a four-eyes principle -- the person who writes a post is never the same person who approves it (unless they are an Owner or Admin).

Notifications

The approval workflow triggers notifications at each transition:

Event	Who is notified
Post submitted for review	Assigned reviewer
Post approved	Post author
Changes requested	Post author
Comment added	Other participants in the review thread

Notifications are delivered both in-app and via email, depending on each user's notification preferences.