Team Roles & Permissions

Role Hierarchy

AdminLocks Cloud uses a four-tier role system to control what each team member can see and do within the Cloud dashboard. Roles are assigned at the team level — each user belongs to one team with one role.

The four roles, from most to least privileged:

Roles are strictly hierarchical — each role includes all permissions of the roles below it, plus additional capabilities. There is no way to create custom roles or selectively grant individual permissions.

Owner

The OWNER role has unrestricted access to every feature in AdminLocks Cloud. There is exactly one owner per team, set when the team is first created. Ownership can be transferred to another team member but cannot be shared.

Owner-exclusive capabilities:

• Billing management — view invoices, change plan, update payment method, cancel subscription
• Team deletion — permanently delete the team and all associated data
• Ownership transfer — transfer the owner role to another admin-level team member
• API key management — generate, rotate, and revoke the team's Cloud API keys

In addition to these exclusive capabilities, the owner has full access to all admin-level features: site management, member management, policy deployment, approval workflows, snapshot triggers, report generation, and branding configuration.

Admin

The ADMIN role is designed for trusted team members who need to manage day-to-day operations without access to billing or destructive team-level actions.

Admin capabilities include:

• Site management — connect new sites, disconnect existing sites, view all site dashboards
• Member management — invite new members, change roles (except to owner), remove members
• Policy deployment — create, edit, and deploy policies to connected sites via webhook
• Approval workflows — review and approve/deny requests from members and viewers
• Snapshot management — trigger remote snapshots, view and delete snapshot records
• Report generation — create, schedule, and send white-label reports
• Branding configuration — update the team's white-label branding settings
• Audit log access — view and export audit logs from all connected sites

Admins can see all sites connected to the team without any site-level scoping restrictions. This makes the admin role appropriate for agency employees who need full operational visibility.

Member

The MEMBER role provides limited operational access. Members can view site data and submit requests but cannot make changes to policies, approve requests, or manage other team members.

Member capabilities include:

• View assigned sites — see dashboard data, audit logs, and snapshots for sites they are assigned to
• Submit requests — create approval requests for actions that require operator review
• View reports — access generated reports for their assigned sites
• Portal access — access the client portal interface at /portal

Members cannot:

• Connect or disconnect sites
• Create, edit, or deploy policies
• Approve or deny requests
• Invite or remove team members
• Trigger snapshots
• Generate or schedule reports
• Modify branding settings

Viewer

The VIEWER role is the most restricted and is specifically designed for end clients. Viewers get a simplified portal experience that shows only what is relevant to them, with no access to the operator dashboard.

Viewer capabilities include:

• View assigned sites — see a high-level overview of their assigned sites
• Submit requests — request changes that an operator must approve
• View reports — access reports that have been shared with them
• View safe actions — see which actions are available without approval

The viewer experience is intentionally minimal. When a viewer logs into AdminLocks Cloud, they are routed directly to the /portal interface rather than the full dashboard. The portal sidebar shows only four sections: Overview, Requests, Reports, and Safe Actions.

Site Membership

AdminLocks Cloud uses a SiteMember model to control which sites each team member can access. This provides per-site scoping so that a member or viewer assigned to one client's site cannot see another client's data.

How Site Scoping Works

• OWNER and ADMIN — automatically have access to all sites connected to the team. They do not need explicit site membership records.
• MEMBER and VIEWER — can only see sites where they have an explicit SiteMember record. If a member has no site memberships, they see an empty dashboard.

Site memberships are managed by admins and owners. To assign a member or viewer to a site:

1. Navigate to the site's settings page in the Cloud dashboard
2. Click the Members tab
3. Search for the team member and click Add

A single team member can be assigned to multiple sites. This is common for members who handle support across several client sites, or for viewers (clients) who own multiple WordPress sites managed by your agency.

Site Membership Matrix

Cloud Portal Access

The Cloud portal at /portal is a separate interface designed for client-facing roles (MEMBER and VIEWER). It provides a simplified, distraction-free experience that hides the complexity of the full operator dashboard.

Portal Sidebar

When a MEMBER or VIEWER logs in, they see a reduced sidebar with four sections:

• Overview — a summary dashboard showing site status, recent activity count, and any pending requests
• Requests — a list of their submitted requests with status tracking (pending, approved, denied)
• Reports — generated reports that have been shared with them or include their assigned sites
• Safe Actions — a catalog of actions that can be performed without operator approval

Route Protection

Operator routes — including /dashboard, /sites, /policies, /approvals, /reports (the management view), and /settings — are blocked for MEMBER and VIEWER roles via both middleware and server-side redirects. If a client-role user attempts to navigate to an operator route directly, they are redirected to /portal.

This protection is enforced at two levels:

1. Middleware — checks the user's role before rendering the page and redirects to /portal if the role is MEMBER or VIEWER
2. Server-side redirect — as a fallback, server-rendered pages verify the role and issue a redirect if the middleware check was bypassed