Team Members With Site and Feature Permissions

If you run an agency, you have probably shared a login over Slack, or forwarded an alert email to whoever looks after that client. Team members in mySites.guru stop all that. Everyone gets their own login, you pick which of your sites they can see, and you decide what they can do on those sites, area by area. If you are still getting your head around the core workflow, start with the guide to managing multiple WordPress sites. Team access is the natural next step once the basics are in place.

The Access column tells you at a glance who has what. Full access means the member can do everything on their sites. A Custom pill means you have narrowed it down, and hovering the pill shows how many areas are on Manage, View and None. Accountants have their own pill, because they are a different kind of account altogether (more on that below).

How do you invite a team member?

Open your Team Members page and click Invite team member. The form has a pane menu down the left:

1. Details: their name, the username they sign in with, and the email address the invitation goes to. We email them a link to set their password.
2. Account type: Team member, which manages sites, or Accountant, which sees invoices and nothing else.
3. Site access: which sites they can see.
4. Permissions: what they can do on those sites.

Click Invite team member at the bottom and they are set up. Once they exist, the same page gains an Activity log pane, a Delete pane, and buttons along the top to send their username, send a password reset, block them, or sign in as them.

Choosing which sites a member can see

Site access is a searchable table of your sites, and the rows you select are the sites the member gets. Select none at all and they get every site, including the ones you add later, which is what you want for a senior colleague and not what you want for a freelancer who looks after three clients.

A member restricted to some sites sees only those sites: their sites list and the counts in their menu cover only the sites you picked. The check also runs on the server for every page and every action, so editing a site’s ID into a URL does not get around it: they get a page saying the site is not one their account owner has given them access to. The Agency API and the MCP server apply the same restriction.

Choosing what a member can do

The Permissions pane starts with one choice. Full access means “Everything on their sites: updates, sign-in, files, the lot.” It is the default, and every member who existed before permissions were added has it. Custom lets you choose, area by area, what they can see and change, and applies to every site picked under Site access.

Custom gives you 14 areas, each set to None, View or Manage. None hides the area completely. View lets them look at it. Manage lets them change things. The table groups the areas by how far they reach into a site: “Looking around” for reading the state of their sites, “Routine work” for jobs that are safe to give a colleague or client, and “Changes the site itself” for code, files, users and admin access.

Two rows are different. Sites has no None, because a member with no view of their sites could not do anything else either. Admin sign-in has no View, because one-click sign-in to a site’s admin is an action with nothing to look at.

Two preset buttons, Viewer and Operator, sit next to “Start from” above the table. Viewer sets every area to View and Admin sign-in to None, so the member can look at everything and change nothing. Operator gives Manage on Backups, Monitors, Alerts and Reports, View on everything else, and None on Admin sign-in, which suits someone who does the day-to-day running of sites but should not be updating code or signing in to production admins. Both are starting points: click one, then change any row you like.

Above the table, a sentence rewrites itself as you click. For the Operator preset it reads “Marileen can run and schedule backups, change monitors, change alert settings and create and send reports, and view the rest. No access to admin sign-in.” It is the quickest way to check you have set what you meant before you click Save changes.

Some common setups

What a restricted member sees

An area set to None disappears for that member. It is gone from their menus, from the Tools list and from the Cmd-K search, so they are not looking at a page of things they cannot click. If they follow an old bookmark or a link a colleague pasted, they get this page instead:

The page names the area but leaves out your email address, which is what you want when the member is a client.

In an area set to View, the pages work normally but the buttons that change something are greyed out. Hover one and the tooltip says why.

When Admin sign-in is None, the one-click admin login links are hidden.

A member on Custom also gets a table at the top of their Your Account page listing all 14 areas, the level you gave them, and what that lets them do, along with how many sites they have access to. They can see their own permissions without having to ask you.

How the permissions are enforced

Hiding a button does not stop someone sending the request by hand, so the server checks too.

Every route in mySites.guru belongs to one of the 14 areas or is marked exempt (signing in, passkeys and the help pages, for example). One check runs before each request reaches its page. It works out the area, treats opening a page as View and anything that changes something as Manage, checks the site against the member’s Site access, and returns the denied page if either check fails. A route that has not been put in an area yet is blocked for team members rather than allowed, and a test lists any route that is unclassified so it gets fixed.

The Agency API goes through the same check and answers with a JSON 403 error saying which area is missing. The MCP server checks each tool call against the member’s permissions as well as the scopes they approved when they connected their AI client. So a member with View on Backups can ask Claude about backup status, and gets an error back if they ask it to start a backup.

Seeing exactly what a member sees

You do not have to imagine how a Custom member’s screen looks. Open them on the Team Members page and click Sign in as. You are switched into their account with their sites and their permissions, and Exit Impersonation in the left menu takes you back. The impersonation post covers it in more detail.

How to impersonate your mySites.guru team membersAccount owners can sign in as any team member to see exactly what they see, their sites and custom permissions included, without their password.Read the full post

Is there a record of who changed what?

Yes. When you save a change to a member’s permissions, it is written to your activity log and to theirs. The entry lists each area that changed with its old and new level, for example “Backups: view → manage”, or the switch between Full access and Custom. If a client asks why they suddenly cannot run backups, the answer is in the log with a date on it.

How do notifications work?

Team members get all notifications by default. They can change their own notification preferences without affecting yours. Changes anyone makes to site config or monitors apply to the site, not the person, so everyone sees the same thing.

How do passkeys and security work?

Team accounts support passkeys: Face ID, Touch ID, Windows Hello, whatever your device offers. There are no codes to type and nothing that can be phished, because the key never leaves their device. If someone on your team still uses password123 for everything, passkeys fix that.

Two Factor Authentication is available too, for teams that prefer it. From the member’s page you can send a password reset, block them, or delete them whenever you need to. That covers their mySites.guru login; for the accounts they hold on the client sites themselves, use the user manager.

For client-facing work you can also remove the WordPress logo from the admin bar and send white-label reports, so what the client sees has your branding.

What about my accountant?

Accountants are a separate account type rather than a permission setting. An accountant sees your invoices and nothing else: no sites, no tools, no team. The Accountant Portal post explains why it is built that way.

A Login for Your Accountant, Not Your SitesInvite your bookkeeper to mySites.guru with access to invoices only. No sites, no tools, no team data, and every other page sends them back to the invoices.Read the full post

What does it cost?

Nothing extra. There are no per-seat fees, and team members, permissions and accountants are part of every plan. Billing, subscriptions and the team itself stay with you, the account owner.

Add Your First Team Member Now

Further Reading

• How to impersonate your mySites.guru team members
• A login for your accountant, not your sites
• Passkeys for secure login to mySites.guru
• The mySites.guru Agency API
• Manage every site from Claude Desktop

Team collaboration is a key topic in our guide to multi-site management.