Book a demo
Book a demo
Login

Playbook WordPress

Separate client work with xCloud teams

Plan team and role boundaries for agency operations and client handover. Each invited user sees only the intended team and sites.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

  • Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: An agency has two clients whose site administrators should never view each other's infrastructure.

    xCloud agent capability boundaries · WordPress roles and capabilities

  • Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.

    xCloud agent capability boundaries · WordPress plugin administration

  • Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: Shared credentials or excessive roles defeat team separation.

    Site backups in xCloud · WordPress hardening handbook

Illustrative situation

Illustrative scenario, not a customer case study: An agency has two clients whose site administrators should never view each other's infrastructure. Each invited user sees only the intended team and sites.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Map client ownership and staff

Where
xCloud selected team/site resource view and owner planning sheet
Permissions
Named xCloud team/site administrator; verify the exact target.
Inputs
Owner, hostname, approved requirements, sample record and decision date. Map client ownership and staff.
Action
List every client, production site, server, billing owner and staff member. Mark which people may see each team's resources and who approves invitations.
Expected result
The client-by-client access matrix has a named approver.
Verify
Compare each hostname and staff identity with the current xCloud resource list.
If it fails
If a site belongs to two clients or ownership is unknown, resolve it before granting access.

Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles

Step 2 of 5

Create team boundaries

Where
xCloud team membership dashboard
Permissions
Named xCloud team/site administrator; verify the exact target.
Inputs
Target team/site, server or plugin version, license and documented prerequisites. Create team boundaries.
Action
In the xCloud dashboard create or select a team per approved boundary and place the intended server or site under its owner. Keep billing and operational ownership explicit.
Expected result
Each client has a deliberate team boundary.
Verify
Check team membership and resource ownership from an administrator account.
If it fails
If ownership differs from the plan, revisit the team design before inviting staff.

Sources: xCloud team roles and permissions · xCloud agent capability boundaries

Step 3 of 5

Assign least-privilege access

Where
xCloud team membership dashboard
Permissions
Named xCloud team/site administrator; verify the exact target.
Inputs
Approved change scope, backup state, selected version and maintenance window. Assign least-privilege access.
Action
Invite named users with the minimum xCloud role needed for their task; keep WordPress editor accounts separate from hosting administration.
Expected result
Staff can perform assigned work without seeing unrelated infrastructure.
Verify
Record the role, invitation state and approver for each user.
If it fails
If a role grants too much access, choose a narrower role or keep the task with an administrator.

Sources: xCloud team roles and permissions · xCloud agent capability boundaries

Step 4 of 5

Test each account’s visibility

Where
xCloud team membership dashboard
Permissions
Named xCloud team/site administrator; verify the exact target.
Inputs
Test accounts, sample content or transaction, expected result and provider access. Test each account’s visibility.
Action
Have each invited user sign in and enumerate visible teams and sites. Ask for a harmless read check on the intended site and a negative check for another client.
Expected result
Each account sees only approved resources.
Verify
Compare actual visibility with the access matrix.
If it fails
If cross-client resources appear, revoke or correct access and repeat the test.

Sources: xCloud team roles and permissions · xCloud agent capability boundaries

Step 5 of 5

Review access after changes

Where
xCloud selected team/site resource view and owner planning sheet
Permissions
Named xCloud team/site administrator; verify the exact target.
Inputs
Observed results, unresolved failures, backup point and owner contacts. Review access after changes.
Action
Set an access-review trigger for departures, contract changes and offboarding. Preserve an owner-controlled emergency account and document revocation order.
Expected result
Team separation remains valid after personnel changes.
Verify
Ask the agency lead to review one departed-user account and emergency contact.
If it fails
If no one owns review, create a real recurring task in the agency's task system.

Sources: xCloud agent capability boundaries · xCloud MCP documentation and connection profiles

Maintenance

Recovery decisions

  • If a user can see an unrelated client team, the xCloud team owner should remove the incorrect membership in the dashboard, inspect recent access and retest both positive and negative visibility. Restoring a WordPress database does not repair xCloud team permissions.

    xCloud team roles and permissions · xCloud agent capability boundaries

AI handoff

Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

  • Manage xCloud team membership and roles dashboard · manual

    Team invitations and role changes require an authorized xCloud team owner in the dashboard. A read-only MCP resource view cannot modify access.

    Checkpoint: Review the exact team, account and role before saving. Sign in as the invited user to verify intended visibility.

    xCloud team roles and permissions · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: Invite named users with the minimum xCloud role needed for their task; keep WordPress editor accounts separate from hosting administration.
  • The business owner compares the controlled sample with this observable result: Each account sees only approved resources.
  • Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage

Sources

Continue

Explore the next WordPress workflow