User Roles & Permissions
Understanding how the plugin uses WordPress roles is key to setting up the right access controls for your organisation.
How roles work in the plugin
The plugin uses the WordPress role system for two distinct purposes:
- Document visibility — Which roles can see, search, and open a document
- Admin access — Which roles can manage documents, settings, and compliance data in the WordPress admin
These two concepts are separate. A user with the Subscriber role (typically a regular staff member) can be given access to read documents, but they cannot open the plugin’s admin screens or edit anything.
The plugin adds its own admin menu, Policy Management, containing Compliance Overview, Acknowledgements, Pending Approvals, Edit Suggestions, Analytics, Tools, Page Gating and Settings. Some items only appear when the related feature is switched on (for example, Edit Suggestions and Page Gating).
Default WordPress roles and what they can do
Administrator
Full access to everything. Administrators can:
- Create, edit, publish, and delete all documents and FAQs
- Open every Policy Management screen: Compliance Overview, Acknowledgements, Pending Approvals, Edit Suggestions, Analytics, Tools, Page Gating and Settings
- Change all plugin settings
- View every user’s acknowledgement records and record an acknowledgement on someone’s behalf (when Allow Acknowledge on Behalf is switched on)
- Read every document regardless of its audience
- Bypass page gating
- Generate attestation exports
- Create user accounts and assign the Policy Auditor role
Editor
Editors manage documents in the same way they manage WordPress posts. Editors can:
- Create, edit, and publish documents and FAQs (including other people’s)
- Review and act on Edit Suggestions, when that feature is switched on
- See change descriptions in a document’s version history when Changelog Description Visibility is set to editors
Editors cannot open Compliance Overview, Acknowledgements, Analytics, Pending Approvals, Tools or Settings, and they cannot generate attestation exports. To let an editor approve version changes, add the Editor role to Approver User Roles under Policy Management → Settings → User Management.
Author
Authors work with documents in the same way they work with posts. Authors can:
- Create and publish their own documents
- Edit documents they wrote
Authors cannot edit other users’ documents or open the plugin’s admin screens.
Contributor
Contributors can draft documents but cannot publish them. Their drafts must be reviewed and published by an Editor or Administrator.
Subscriber
The typical “staff member” role. Subscribers can:
- Read documents whose audience includes their role
- Acknowledge documents they are asked to acknowledge
- View their own acknowledgement history on the My Acknowledgements page
- Bookmark documents and save searches
- Submit edit suggestions, if Edit Suggestions is switched on and their role is selected under Suggestion Roles by Document Type
- Rate FAQs and documents as helpful or not helpful
Subscribers have no access to the WordPress admin beyond their own profile.
The Policy Auditor role
The plugin creates a custom role: Policy Auditor.
This role is designed for external auditors who need read-only access to your compliance records during an audit. A Policy Auditor can:
- View the Compliance Overview dashboard
- View the Acknowledgements screen and acknowledgement records (read-only)
- View the Analytics dashboard
- Read every document, whatever its audience, including the version history shown on each document page
- Generate and download attestation exports (CSV and PDF)
- View user lists (read-only)
A Policy Auditor cannot:
- Create, edit, or publish documents
- Approve versions or moderate edit suggestions
- Record acknowledgements on anyone’s behalf
- Open Settings, Tools, or Pending Approvals
- See or modify user accounts
Creating an auditor user:
- Go to Users → Add New User.
- Create a WordPress account for the auditor.
- Set their role to Policy Auditor.
- Share the login details with the auditor.
- When the audit window closes, delete the account or change its role.
Role-based document visibility
Two settings on each document control who can see it. Both are in the Document Settings box on the document edit screen:
- Confidentiality — Set to Public to let anyone, including logged-out visitors, read the document. Internal Use, Confidential, Restricted and Unclassified documents require visitors to log in and are role-gated.
- Target Audience (Roles) — Tick the WordPress roles allowed to read a non-public document. If you leave every role unticked, any logged-in user can read it.
Together these settings control:
- Whether the document appears in the Document Hub
- Whether the document appears in search results
- Whether the document can be opened directly by URL
- Whether the document can be downloaded as a PDF
Administrators and Policy Auditors can always read every document. A document with a future Effective From date stays hidden from staff until that date (editors can still preview it).
Who must acknowledge is set separately, in the Acknowledgement panel of the editor sidebar (Target roles and Target user lists). Make sure everyone you ask to acknowledge a document can also read it.
Example setup:
| Document | Confidentiality | Target Audience (Roles) |
|---|---|---|
| Staff Code of Conduct | Internal Use | Subscriber, Author, Editor, Administrator |
| Management Performance Policy | Confidential | Editor, Administrator |
| Finance SOPs | Restricted | (custom Finance role) |
| Public Compliance Statement | Public | (none needed) |
A staff member with the Subscriber role who visits the Management Performance Policy URL sees an “Access Restricted” message instead of the content — the document is genuinely inaccessible, not just hidden from menus. Logged-out visitors see a “Login Required” message. You can change the wording of both messages under Policy Management → Settings → User Management → Access Control Messages.
Custom roles
If your organisation has custom WordPress roles (added by your theme, a membership plugin, or another plugin), the plugin works with them automatically. Custom roles appear in:
- The Target Audience (Roles) field on each document
- The acknowledgement Target roles list
- The Default Audience step of the Setup Wizard
- The Compliance by role table on the Compliance Overview dashboard
- The User Role filter on the Analytics dashboard
You do not need to do anything to add custom roles to the plugin — they are discovered automatically.
Changing what each role can do
WordPress capabilities control what each role can do. You can grant the plugin’s capabilities to other roles using a role management plugin (such as Members or User Role Editor).
Plugin-specific capabilities:
| Capability | Granted by default to | What it controls |
|---|---|---|
dpma_manage_settings |
Administrator | Change plugin settings; Pending Approvals; Page Gating |
dpma_manage_acknowledgements |
Administrator | Manage acknowledgement records, including acknowledging on someone’s behalf |
dpma_view_acknowledgements |
Administrator, Policy Auditor | View acknowledgement records and generate attestation exports |
dpma_view_analytics |
Administrator, Policy Auditor | Open Compliance Overview and Analytics |
dpma_view_all_documents |
Administrator, Policy Auditor | Read every document regardless of its audience |
dpma_edit_documents |
Administrator, Editor | See change descriptions when they are limited to editors |
dpma_approve_edits |
Administrator, Editor | Review and act on Edit Suggestions |
Creating and editing documents uses the standard WordPress post permissions, so Editors, Authors and Contributors work with documents exactly as they do with posts. The Tools screen requires full administrator rights.
🔒 Pro feature — requires the Pro plugin.
Pro screens and who can use them
The Pro add-on uses the same permissions. With default roles:
| Screen or action | Needs | Administrator | Policy Auditor | Editor |
|---|---|---|---|---|
| Document Compliance dashboard, including Bulk Edit | Manage settings | Yes | No | No |
| Calendar | View analytics | Yes | Yes | No |
| Frameworks (Framework Library) and the Framework Editor — corpus, briefs, auto-fetch | Manage settings | Yes | No | No |
| Coverage & Gaps — view the readiness matrix | View acknowledgements | Yes | Yes | No |
| Coverage & Gaps — Map policy, + Create, coverage detail, Export Survey Packet | Manage acknowledgements (plus permission to edit or create the document) | Yes | No | No |
| Evidence Pack (a tab on Tools) | Full administrator rights to open Tools, and Manage acknowledgements to generate | Yes | No | No |
| AI Costs tab on Analytics | Manage settings | Yes | No | No |
| Run Compliance Audit on a document | Permission to edit the document | Yes | No | Yes |
| Approve AI audit changes on Edit Suggestions | Review and act on Edit Suggestions | Yes | No | Yes |
| Pending Approvals, including Approve (bypass chain) | Manage settings | Yes | No | No |
Approval-chain approvers don’t need any of these permissions — they approve from the link in their email. If the Pro licence is not active, Document Compliance and Calendar show an “activate your licence” page instead.
Multisite considerations
On a WordPress multisite network, activate the plugin on each site individually — network activation is not supported. Each site has its own document library, acknowledgement records, roles, and settings. There is no “share policies across the network” feature. If you need documents visible across several sites, manage them on one site and link to that site’s Document Hub from the others.
Each site’s Policy Auditor role and compliance data are independent.
Was this helpful?
Thank you for your feedback!