Tool Evaluation
Part of Content management systems for marketing teams
Checking content permissions during a CMS trial
Use a role-by-role CMS trial to check who can view, edit, publish and administer content, including documented product limitations.
Create separate accounts for each role your team will use, then test the content actions each role should allow or block. Check a restricted draft and published content: a role name or permissions screen alone does not prove who can edit or publish.
Write the access matrix first
Choose a safe sample article and a restricted draft. For each role, specify whether it may view the draft, edit text, change the content structure, approve, publish, withdraw or change access. Include agency and temporary users if they take part in publishing.
| Example role | Intended content actions | Prohibited action to attempt |
|---|---|---|
| Writer | Create and revise assigned content | Publish or change roles |
| Reviewer | Read and return work for changes | Bypass the final release decision |
| Publisher | Release an approved version | Change site-wide access without authority |
| Administrator | Configure access as assigned | Act through an unaccountable shared login |
These are example requirements; agree on your own before examining a product.
Include both new and published content. Editing a live item can have a different consequence from editing an unpublished draft.
Know what the documentation establishes
WordPress defines six roles: Super Admin, Administrator, Editor, Author, Contributor and Subscriber. Each has default capabilities, but capabilities can be added or removed and roles introduced or removed. Test post capabilities such as edit_posts, edit_others_posts, edit_published_posts and publish_posts; Subscriber has only the read capability, while Super Admin has all possible capabilities.
Drupal groups permissions into roles, including Anonymous user and Authenticated user. Check the permissions assigned to each role and the roles assigned to each account; an Administrator role with all permissions may depend on the installation profile.
Drupal’s Content Moderation module can keep a live published version while a separate working copy is reviewed. The Editorial workflow is created by the standard installation profile; check its transition permissions at People > Permissions and confirm it is applied to the content type under test. The module requires Drupal 8.4 or later and can be added to Block Content, Taxonomy and Content (Node) entities.
Contentful offers custom roles. Test each intended role against the matrix, including whether it can publish; the custom-role label alone does not establish which publishing actions are allowed.
Webflow has site roles and permissions, as well as locale-specific access. Test each intended role on sample content and repeat the checks for relevant locales; do not infer publishing rights or locale boundaries from a role name.
Content Permissions by CMS Platform
- WordPressSix default roles (Super Admin, Administrator, Editor, Author, Contributor, Subscriber); capabilities can be customised. Test edit_posts, publish_posts, etc.
- DrupalRole-based permissions; supports Content Moderation module (Drupal 8.4+). Workflow transitions must be checked in People > Permissions.
- ContentfulCustom roles available; publishing rights must be tested explicitly—custom role label ≠ granted actions.
- WebflowSite roles and locale-specific access; test both content and locale boundaries directly—do not assume from role name.
Run the trial as ordinary users
Have each role open the sample content, perform allowed work and attempt a prohibited action. Record the result alongside the account, plan and configuration used.
Repeat important actions through any API or automation the organisation intends to use; an editor interface restriction should not be assumed to govern another route.
Change the sample item’s state and retest access. Check whether the writer can edit it after review, whether the reviewer can see an unpublished correction, and whether the publisher can release a version changed since approval.
The expected result depends on the team’s process. If the CMS does not enforce a rule, record the additional check needed before release.
Finally, remove a temporary user’s access and check the result. Record each intended allowance, attempted denial, observed result and untested route, then use any gaps to decide whether the setup is acceptable.
