WebsiteDesignOutsource.com blog
Set CMS Preview Permissions for an Outsourced Website Team
Let external designers and editors review draft pages without giving them unnecessary publishing, user, or configuration control.
**Published: September 3, 2026**
Preview access sounds harmless because a draft is not public. In many content management systems, though, the account that previews a page can also edit templates, invite users, reveal unpublished business material, or publish changes. An outsourced website team needs a reliable way to see realistic content without inheriting broad administrative power.
A CMS preview permission plan starts with tasks. It identifies what each external contributor must view or change, which draft material is sensitive, how preview links behave, and who retains publishing authority. The plan should fit the platform, but the ownership rule is consistent: the client controls the system and grants the least access that supports the work.
Map the preview jobs
List what the outsourced team will do in the CMS. A designer may need to review real headings and image crops. A developer may need to test a component against draft content. An editor may need to revise assigned pages. A QA reviewer may need read-only access to scheduled material.
Translate each job into actions: view drafts, create entries, edit assigned fields, upload approved assets, request review, or inspect revision history. Do not begin with a generic role name such as "contractor." Platform roles often bundle permissions that do not match the project.
Note which tasks can occur outside the CMS. If an exported content sample is enough for early layout work, there may be no reason to grant system access yet.
Inventory sensitive draft material
Draft content can include future announcements, internal contacts, legal reviews, account details, or campaigns under embargo. Record the content spaces and fields an external team may access. Separate routine page copy from restricted material.
Check whether preview responses include hidden fields, metadata, or application data that the visible page does not show. A read-only interface can still reveal more than the reviewer needs. Ask the platform owner to confirm how role rules apply to APIs, media libraries, revisions, and previews.
Use synthetic or redacted content when realistic structure matters but the actual information does not. Do not move confidential data into a design tool simply to avoid CMS controls.
Choose named, limited roles
Give each contributor an individual account. Map the selected role to the task list and record exceptions. Publishing, user administration, plugin installation, environment configuration, billing, and security settings usually belong with client owners unless the approved scope specifically requires otherwise.
Where the CMS supports content-level restrictions, limit access to the relevant site, locale, collection, or project. Set expiration dates for temporary accounts. Require the client’s approved authentication method and recovery process.
Shared credentials weaken accountability and make removal difficult. If the platform lacks suitable roles, document the limitation and choose a controlled workaround rather than pretending a broad account is safe.
Treat preview links as access paths
Some systems generate secret preview URLs that work without a login. Determine whether links expire, can be revoked, reveal unpublished routes, or grant access to anyone who receives them. Decide where the team may share them and how reviewers report accidental exposure.
Do not place long-lived preview links in public tickets, screenshots, or documentation. If a link reaches restricted content, handle it according to the client’s access policy. A difficult-to-guess URL is not the same as an authenticated workspace.
For static or headless sites, document which environment renders the preview, what source revision it uses, and whether it calls production services. The permissions plan must cover the whole preview path, not only the CMS login.
Separate editing from publishing
Create a review state between draft editing and public release. The outsourced team can prepare changes and request approval, while a named client owner decides whether and when to publish. Record required checks for content, layout, links, metadata, accessibility, and legal or brand review where applicable.
If an external specialist must publish within the agreed service, use a specific approval record and a narrow release window. Avoid standing administrator access when a temporary role or client-executed release can meet the need.
Make rollback ownership explicit. The person who can press publish may not be the person authorized to restore an older version or approve the business consequences of a reversal.
Test permissions before production work
Use a representative account with the proposed role. Confirm it can perform every required task and cannot reach prohibited functions. Check direct URLs, APIs, media libraries, user lists, settings, and other sites in the same account where relevant.
Test draft, scheduled, archived, and restricted entries. Verify what happens when a preview link expires or an account loses access. Record the platform version, role configuration, test cases, and result.
Do not test with real submissions or unsafe changes to a public site. Use the approved environment and data set. Escalate any permission gap to the platform owner before compensating with a broader role.
Review and remove access
Set review points at onboarding, scope changes, staff changes, and project close. Compare active accounts with the current team roster and task list. Remove accounts that no longer have work, revoke preview links when supported, and transfer any client-owned drafts or assets.
Keep an access removal record with the account, scope, owner, and completion date. Do not preserve passwords or authentication secrets in the handoff. Confirm that automated tokens, integration keys, and local sessions are included when they were part of the preview path.
The client should retain an administrator and recovery route throughout the engagement. External access should never become the only way back into the system.
Further reading
Prepare an access control checklist
A compact permission record
For each person, record the name, company, project task, CMS role, content scope, environment, grant date, review date, expiry, approver, and removal status. Link to the role definition and test evidence. Keep the record private and client-controlled.
This small discipline makes preview work easier to delegate. Designers see realistic pages, editors work in the correct source, and the client retains clear authority over publication and system administration.
Frequently asked questions
Is read-only access always safe?
No. Read-only users may still see confidential drafts, media, revisions, or metadata. Review both the allowed actions and the information exposed.
Should designers publish their own approved pages?
That depends on the agreed operating model. Separate preparation from approval, and keep publishing permission as narrow and time-bound as the workflow allows.
What if the CMS has only administrator and editor roles?
Document the gap. Consider a separate environment, exported content, client-operated preview, or another controlled method before granting unnecessary administrator rights.