Strapi review workflows for editorial approval

Review workflows are the feature that decides the plan. Strapi's self-hosted pricing page lists review workflows as an Enterprise feature, so a Growth or Community deployment cannot enforce named approval stages inside the CMS. Before you design stages, decide whether the CMS itself must block publishing until an approver has signed off. If it must, Enterprise is the only listed route. If approval can live in editorial convention and a ticket trail, a lower plan may be enough, but then you carry the enforcement risk yourself.

The Enterprise decision is rarely about one feature. The same pricing page places audit logs in Enterprise, lists SSO as an add-on for Growth and as included in Enterprise, and starts content history and releases at Growth. Work out which of these your editorial and compliance requirements actually depend on. If you need approval gates and audit logs together, the cost comparison is against a package, not a single feature. Also note that Strapi SSO covers administrator login to the admin panel only, so reviewer identity and role mapping still need a separate design on any plan.

Enterprise pricing is custom, so no figure in this section should be treated as a budget. Ask Strapi for a written quote that states the license term, the renewal conditions and any annual uplift, the number of admin seats, the support level, and whether SSO and audit logs are included. Compare that against the Growth price, which Strapi lists at 45 US dollars per month including 3 users and 15 US dollars per additional user. Editors, reviewers and publishers all count as seats on Growth, so an approval chain with many reviewers can change the Growth total. Implementation effort is a separate line that is quoted from the scope, not from the license.

On a lower plan, the team loses the native stages and the enforcement that come with them, and must build substitutes by hand. Illustrative example: a status field on each content type, role checks in custom middleware or policies, a webhook that notifies reviewers, and a log of approvals kept outside Strapi. Each piece is code you must write, test, document and update through Strapi 5 upgrades. The main risk is a bypass: custom checks often guard the admin panel but not every API path, so confirm that any publish action is blocked in the Document Service API as well as in the admin UI before you rely on it.

Before committing, ask Strapi to confirm in writing that the review workflow features in your target version cover the stages, roles and publish gate you have designed, and that the Enterprise license terms, which sit under a separate license for code in the ee directories, are acceptable to your legal team. Ask whether an evaluation environment is available so the team can test the gate with real roles before purchase. Keep the approval design document as the reference for the quote, so the scope you priced and the scope you build match.

Design the editorial path on paper before you configure anything in the Strapi admin panel. Start by listing each stage an entry passes through, such as draft, editing, approval and published, and then name one accountable owner for each stage. For every stage, write down which roles can move an entry into it, which roles can move it out, and where it can go next. A short matrix with stages as rows and roles as columns is usually enough to show gaps before any permission is set. Treat this matrix as the design document that the configuration must match.

Two failure points appear more often than others. The first is a stage with no owner. If nobody holds the right to move entries out of a stage, content stops there and editors start working around the workflow. The second is a publisher who can bypass approval through another permission. A role may be denied the approval transition but still hold a permission that changes publication state directly, or an API token may have publish rights that no one reviewed. Check every permission that can change publication status, including those granted through custom roles, admin roles that can edit content types, and API tokens, not only the workflow settings themselves.

Content types do not always need the same approval path. A press release may need legal review, while a product FAQ may need only editorial sign-off. Decide whether each content type gets its own workflow or whether several content types share one, because the number of workflows and stages will shape how much administration your team takes on over time. If you use localization, also confirm with your Strapi version and plan whether approvals apply per locale or to the entry as a whole, and record that answer in the design matrix before you build.

Validate every permission in staging before production use. Create one test account for each role in the matrix, plus one account that holds the combined permissions of a single person who may act in several roles. Using each account, attempt every allowed transition, every blocked transition and a direct publish, in both the admin panel and the API where the content is served. Record the expected and actual result for each attempt. Review workflows are an Enterprise feature in Strapi's self-hosted plans, so confirm your plan before you start this design, and keep the test record as evidence for your change review.

Test every approval path in a non-production copy of the instance before any editor is told the workflow is live. The test plan should cover each role against each stage, and each transition between stages. For every role, record what it can see, what it can move, and what it is blocked from doing. A test plan that only confirms the happy path, where an editor submits, a reviewer approves and the content publishes, will miss the failures that matter most to an approval process.

Three negative tests deserve their own cases. First, attempt to publish from a role that has no approval authority, using both the admin panel and direct REST or GraphQL requests. Second, attempt to reach the published state while skipping the required stage, for example by changing status through an API call or a script that uses an account with broad permissions. Third, move content backward after it has been approved, and confirm whether that movement resets the approval or leaves a published version unreviewed. Confirm with your Strapi configuration whether the admin panel restrictions also apply to API requests, because a control that holds in the interface but not in the API is not an approval control.

Run the tests against a copy of production content on the same Strapi version and the same plugin set as the production instance. Keep the database engine, Node.js version, locales and content types identical as well. Workflow permissions and stage assignments are tied to the content types and configuration of the instance, so a test on a fresh install with sample data can pass while production fails. Ask your team to confirm the restore procedure for the copy and to decide how personal data in that copy will be handled before testers access it.

Record each test with an identifier, the role used, the starting stage, the action attempted, the expected result, the actual result, the tester and the date. Also record the Strapi version, the plugin versions and an export of the workflow configuration at the time of testing. Keep these results with the release record, because they show what was verified and under which configuration. Your auditors or certification body will decide whether this evidence meets their requirements. DeployOpen can prepare the test results and the configuration records, but it does not issue audit reports or attestations.

Repeat the approval path tests after any change to roles, stages, permissions, plugins or the Strapi version, and before each upgrade is promoted. Assign one owner for the test plan and one person to sign off the results before editors receive access. A written sign-off step turns the test record into a decision that can be reviewed later, and it gives editors a clear date from which the workflow can be relied on.