A multi-department website needs clear boundaries around who can change which content. Start with a small role-and-template matrix, then test it using ordinary accounts. The goal is to give contributors enough control to maintain their information while keeping shared content accountable.
Map responsibilities before assigning accounts
Consider a fictional community center with Activities, Facilities and Membership departments. Each owns its service facts. A central web team owns navigation, templates and common contact information. An accountable service owner approves consequential changes before a publisher releases them.
Record the action and its scope separately. “Can edit” is incomplete: can the person edit their own drafts, every item in their department, or the entire site? Include assets, previews, exports and configuration in the review. Removing a menu option alone does not establish that the underlying action is denied.
WordPress documents roles as sets of capabilities, with permissions varying by role and installation. Its role names illustrate why you must inspect actual capabilities. A built-in Author or Editor role is not automatically a department boundary.
Write an action and ownership matrix
| Role | Allowed work | Boundary to test |
|---|---|---|
| Department author | Create and revise their department drafts; upload approved asset types. | Cannot publish or edit another department. |
| Service owner | Review and approve factual changes for the assigned service. | Approval applies to the exact revision. |
| Publisher | Release approved items and verify public output. | Cannot silently broaden account permissions. |
| Template maintainer | Change shared layouts through a reviewed release. | Content authors cannot alter global structure. |
| Account administrator | Assign approved access and remove obsolete access. | Administration is separate from routine writing. |
This is a policy to implement and test, not a claim that every CMS supports these boundaries without configuration. A small team may combine roles, but should still record who reviewed and released a consequential change. Use named accounts so actions can be attributed.
Define what a template protects
A service template might require a title, purpose, eligibility and next action, while keeping the site header and primary navigation centrally managed. Give authors structured fields for the information they own. Explain which headings are supplied automatically and which they should add within the body.
Test long headings, optional sections, portrait and landscape images, and narrow-screen output. Avoid making essential information dependent on a layout that only works with short sample text. Keep shared facts such as general opening hours in an owned record when all affected pages really use the same value.
Test grants and denials using ordinary accounts
- Create a harmless draft in a test area using an Activities author account.
- Confirm that permitted edits and approved uploads work.
- Attempt the corresponding protected actions: another department's edit route, direct publication and template configuration. Record the expected denial.
- Submit a revision, approve the exact version and publish through the intended accounts.
- Check the public version and action history. Confirm that an unapproved later edit remains in the appropriate state.
- Remove the test assignment and confirm access ends, including any active sessions according to the platform's documented behavior.
Use approved test data and a test environment. Ask the system administrator to verify enforcement at the server/API layer where relevant. Record version, configuration, account, action and observed result so a later upgrade can repeat the checks.
Make handover part of the workflow
When staff change roles, reassign content ownership and queued reviews as well as account access. Keep a named substitute for absences. Review access when teams reorganize, templates change or a new content type is introduced.
Download the role matrix and rollout checklist. Pilot one department first, resolve confusing fields and permission gaps, then extend the configuration. Keep urgent corrections connected to the documented lifecycle and approval process.