Touchscreen Recognition Display Role Access Matrix: Permissions for Editors, Reviewers, and Admins

The short answer: a well-structured matrix assigns four core roles—Content Contributor, Editor, Reviewer/Approver, and CMS Administrator—each with a distinct permission set, so no single user can both create content and push it to the live display without a second set of eyes. The full matrix table and role-by-role breakdowns below give you everything you need to configure and document that structure.

The Four Core Roles

Assign a named individual—not just a job title—to each role before you configure CMS permissions. A role tied only to a title drifts when staff turn over; a role tied to a named person with a documented backup stays current through every transition.

Full Role Access Matrix

Use this table as the starting point for your CMS permission configuration. Mark each cell Allow, Deny, or Conditional—where Conditional means the action requires written sign-off from a second authorized user—and store the completed matrix in a shared document your entire team can access.

Conditional means the action requires documented authorization from a second role owner: the Reviewer/Approver must authorize any Administrator emergency approval bypass, and both the Reviewer/Approver and a second Administrator must sign off before a permanent deletion executes. Log every conditional grant in the audit log at the time the exception is made.

Role-by-Role Permission Detail

Content Contributor Permissions

The Contributor role is designed for the widest possible pool of trusted users. Because contributors cannot publish or approve, the risk of an unchecked error reaching the live display is low—the workflow itself provides the safeguard.

What Contributors Can Do:

1. Log in and create a new content draft from scratch.
2. Upload photos, award documents, and supporting media to their draft.
3. Edit their own draft at any point before it is submitted for review.
4. Submit the draft to the review queue.
5. Respond to return requests from the Reviewer by revising and resubmitting.
6. View the status of their own submissions: submitted, in review, approved, published, or returned.

What Contributors Cannot Do:

• Edit another user’s draft or any content they did not originate.
• View the full review queue or other contributors’ submissions.
• Access the live content on the display through the CMS backend.
• See or export the audit log.
• Create, modify, or view other users’ accounts or permission levels.

Schools running academic honor roll recognition alongside athletic displays benefit from restricting Contributor access to the relevant program year or category: a booster volunteer entering Class of 2026 inductees should not be able to view or overwrite records from earlier classes.

Editor Permissions

The Editor role adds queue visibility and cross-user draft editing to the Contributor permission set. Assign the Editor role to staff responsible for formatting consistency, photo quality review, and content completeness before formal accuracy review begins.

What Editors Can Do (in addition to Contributor permissions):

1. View all drafts currently in the submission queue, regardless of who submitted them.
2. Edit any draft before it is submitted for review—format corrections, caption edits, image swaps.
3. Manage the shared media library: upload, organize, and tag assets.
4. Return an incomplete draft to the originating Contributor with a written note explaining what is missing.
5. Submit any draft to the review queue, including drafts they did not originate.

What Editors Cannot Do:

• Edit content that has entered the review stage or been formally approved.
• Approve, reject, or return content that is already awaiting a Reviewer decision.
• Publish, schedule, archive, or delete any content.
• Access or export the audit log.
• Create or modify user accounts.

For programs managing display content that spans multiple recognition categories—athletic halls of fame, academic honor rolls, performing arts recognition, and donor acknowledgment walls—the Editor role prevents version conflicts when multiple contributors submit content in the same cycle.

Reviewer / Approver Permissions

The Reviewer/Approver is the accuracy gate. Their permission set gives them full read access across the queue, the ability to intervene at any stage before publication, and the authority to clear or block content from reaching the display.

What Reviewers / Approvers Can Do:

1. View all content in the queue at every stage: submitted, in editing, pending review, approved, and live.
2. Edit content currently in the review stage—correcting factual errors before making an approval decision.
3. Return content to the Editor or Contributor with specific correction instructions.
4. Approve content for publication, clearing it for the CMS Administrator to push live.
5. Reject content that cannot be corrected without a full resubmission.
6. Place a hold on content pending additional verification, useful when a record dispute or donor agreement question arises.
7. View the audit log to confirm that required submission and editing steps were completed.
8. View the current user permission list in read-only mode.

What Reviewers / Approvers Cannot Do:

• Publish content to the live display. The separation between approval authority and publish authority is the most critical safeguard in the matrix; maintain it even when it feels like an extra step.
• Change user permissions or create new accounts.
• Export the audit log.
• Delete media assets or content records.

For programs where digital display data integrity is a governance priority, the Reviewer/Approver role should be held by the individual with the deepest knowledge of the records being displayed—typically the athletic director for athletics content and the archivist for historical institutional recognition.

CMS Administrator Permissions

The Administrator holds the highest privilege level. Assign this role to the fewest people possible—one primary and one named backup—and reserve it for system operation, not routine content creation. The Administrator’s job is to publish, protect, and maintain the system.

What CMS Administrators Can Do:

1. Publish approved content to the live display, including scheduled future publishing.
2. Edit live content when a post-publication correction is required, and log the change immediately in the audit log.
3. Roll back live content to a previous version, with Reviewer/Approver authorization logged before execution.
4. Archive content being retired from the display.
5. Soft-delete and permanently delete content, with a second sign-off required for permanent deletion.
6. Create, modify, and deactivate user accounts.
7. Assign and revoke role permissions for all users.
8. View and export the full audit log.
9. Configure display settings and manage the technical platform.
10. Delete media library assets after confirming no live content references the asset.

What CMS Administrators Should Not Do (by convention, even if technically permitted):

• Originate content or submit drafts they will later publish without a separate Reviewer/Approver sign-off.
• Approve their own content submissions (use the Conditional flag and require a second Reviewer/Approver authorization).
• Change their own role or permission level without a documented request from the program owner.

Schools building halls of fame that preserve institutional records alongside athletic achievements should document the Administrator role in the school’s IT governance policy—not just in the CMS settings—so the designation and its requirements survive a staff transition.

Configuring the Matrix in Your CMS

Step 1: Audit Your Current Permission State

Before configuring any new roles, document who currently has access and what their permission level is.

1. Log in to the CMS with Administrator credentials.
2. Navigate to the user management or permissions panel.
3. Export or screenshot the current user list with their assigned roles.
4. Compare each user’s current role to the matrix above. Flag any user who holds more permissions than their function requires.

Step 2: Confirm Role Structure

Most CMS platforms use one of three permission structures:

Step 3: Assign Named Users to Roles

1. Remove accounts for any users whose role has changed or who no longer need access.
2. Assign each current user to the appropriate role based on the matrix.
3. Confirm that no user holds more than one role unless a documented exception exists.
4. Record the final assignments in a Role Assignment Document stored outside the CMS.

Step 4: Test Permissions Before the Configuration Goes Live

For each role, log in as a test user and confirm that the permissions behave exactly as documented in the matrix.

1. Confirm that a Contributor account cannot view other users’ drafts or access the live display.
2. Confirm that an Editor cannot publish, approve, or access the audit log.
3. Confirm that a Reviewer/Approver cannot access the publish control or user management panel.
4. Confirm that an Administrator can successfully publish a piece of approved content and that the action appears in the audit log.

Record the test date and results as an audit log entry.

Emergency Access and Conditional Grants

No access matrix survives an academic year without at least one situation where the standard workflow creates a bottleneck. Document how you handle those situations before they arise.

When the Reviewer / Approver Is Unavailable

If content must be published and the designated Reviewer/Approver is unreachable:

1. The designated backup Reviewer/Approver assumes approval authority.
2. If no backup is available, the CMS Administrator may exercise Conditional Approval for time-sensitive content such as pre-game recognition updates or event-day additions.
3. The Administrator logs the exception with the reason, a record of the attempted contact with the primary Reviewer/Approver, and a post-publish review date within two business days.
4. The primary Reviewer/Approver logs their retrospective review and formal approval upon return.

When an Administrator Account Must Be Shared

Shared Administrator credentials are a security risk. If a coverage gap makes temporary sharing unavoidable:

1. Document the shared-access period, the names of both individuals using the credentials, and the specific reason.
2. Reset the password and restore individual credential use as soon as the gap is resolved.
3. Review the audit log for the shared-access period and confirm that every action during that window was authorized.

For programs where digital hall of fame data integrity intersects with institutional accountability, documenting exceptions is as important as documenting the standard policy—undocumented exceptions become unacknowledged precedents that erode the matrix over time.

Annual Matrix Review

The role access matrix is a living document. Treat it as a policy requiring an annual review, not a one-time setup task.

Conduct a review when any of the following occur:

• A staff member who holds a CMS role leaves the school or moves to a different position.
• A new content type—a new award category, a donor recognition tier, a new display location—is added to the program.
• The CMS platform is updated and permission settings may have changed as a result.
• An audit exception or access incident occurs.
• The annual academic year transition in July or August, before the new content cycle begins.

Annual Review Checklist:

1. Export the current user and role list from the CMS.
2. Compare it against the Role Assignment Document stored outside the platform.
3. Confirm that every current user still holds the appropriate role for their current function.
4. Remove or downgrade accounts for staff who have left or changed roles.
5. Confirm that Conditional permission procedures are still documented and known to the relevant role owners.
6. Sign and date the reviewed matrix and file it with the audit log.

Schools managing youth sports recognition and awards programs with high volunteer turnover should conduct this review at the start of each sports season rather than only annually—seasonal contributors added in the fall often still hold active accounts the following spring.

Programs building recognition displays that include academic all-Americans and scholastic achievement displays alongside athletic halls of fame benefit from adding a Content Category column to the Role Assignment Document, so each Contributor and Reviewer is mapped to the specific content types they are authorized to handle—not just to the CMS platform as a whole.

Role Access Matrix: QA Checklist

Before finalizing your matrix configuration, verify every item below.

• Every CMS user is assigned to exactly one role, or holds a documented exception for dual-role access.
• No Contributor or Editor account holds publish, approve, archive, or delete permissions.
• No Reviewer/Approver account holds publish, account management, or audit export permissions.
• The Administrator role is held by the fewest users necessary—one primary and one named backup.
• A named backup exists for every role in the matrix.
• The Conditional permission procedure for emergency approvals is written down and known to both the Administrator and the backup Reviewer/Approver.
• The Role Assignment Document is stored outside the CMS and is accessible to the program owner without logging in to the platform.
• Permissions have been tested by logging in as a representative test user for each role.
• The audit log captures user and role assignment changes as a distinct event type.
• An annual review date is calendared for the next academic year transition.