Roles that map to real jobs
Owner, administrator, technician, analyst, billing and client. Each carries a sensible default permission set that you can adjust rather than build from nothing.
Team and client access
Nobody needs the admin password again
Granular roles scoped to individual sites or whole clients, so a junior can run approved updates without being able to delete a backup, and a client can see their own reports without seeing anyone else's portfolio.
Included on every plan. No add-on pricing.
Team and accessLive
Team members
9
2 contractors
Client logins
24
portal only
2FA enforced
100%
all seats
Shared passwords
0
none needed
AMAmara O.
FullJTJonah T.
ScopedRCRea C. (contractor)
TemporaryCLHarvest Collective
Portal The problem
Shared credentials are the default and they are a liability
Most small teams run on a shared password manager entry and good intentions. It works until somebody leaves, a laptop is lost, a contractor finishes a project, or a client asks who exactly made a change on the 14th and nobody can answer.
Shared credentials also make delegation risky. Handing a junior the admin password to run a routine update means handing them the ability to delete the site, so the work stays with the person who should be doing something more valuable.
What this looks like without a platform
- One admin account shared across four people and a contractor
- No way to tell who made a change
- Offboarding that means rotating passwords on thirty sites
- Giving a client an admin login because there was no other option
How it works
How WordPress team management and access control work
Scoped to sites or clients
A contractor gets access to four sites for the duration of a project. An account manager sees every site belonging to their clients and none belonging to anyone else.
Permissions at action level
Separate the ability to run an update from the ability to approve one, restore a backup, change a policy, or invite a user. Most incidents come from someone having more power than their job requires.
Client access without WordPress access
Clients get a portal login showing uptime, reports and tickets for their own sites. They never receive a WordPress administrator account, which is better for both of you.
In practice
WordPress team access and accountability that survives an argument
Every action attributed
Who did what, on which site, at what time, and what the result was. Including one-click logins, which are recorded as sessions rather than disappearing into wp-admin.
Approval workflows
High-risk actions can require a second person's sign-off. Useful for client tiers where changes need explicit authorisation.
Clean offboarding
Revoke a person once and their access disappears everywhere immediately. No password rotation across thirty sites.
SSO and SCIM on Scale
SAML single sign-on and directory provisioning so access follows your identity provider rather than a separate list.
At scale
WordPress site access management across every client
- Unlimited team seats
- Per-site and per-client permission scoping
- Time-limited access grants for contractors
- Two-factor authentication enforced across the team
- Session recording for one-click logins
- SAML SSO and SCIM provisioning
Answers
Questions about team and client access
What people ask before they turn this on.
No. Studio includes five seats and Scale includes unlimited seats. Client portal logins never count as team seats on any plan.
Yes. Client users see only their own sites and only the surfaces you enable: uptime, reports, tickets. They never receive a WordPress administrator account.
Revoke them once and access ends everywhere immediately. Their historical actions remain in the audit log, correctly attributed.
Early access open
Try team and client access on your own sites
Connect a site in under two minutes and see this working against something real. Free during early access.
Free during early access. Keep your data, export any time.