Separating client work with Google Workspace accounts

An agency that gives each person a Google Workspace account, and gets into client tools through invitations to that address, never has to hold a client's Google password. The client adds maria@youragency.com to their Google Ads, Analytics or Search Console, Maria signs in as herself, and her access ends the day you suspend her. Separate client accounts are rarely needed; what needs separating is people.

Google Workspace accounts per person, not separate client accounts

The tempting setup is one Google account per client, acme@youragency.com, that everybody on the Acme team signs in to. It looks tidy in the Admin console and it is the shared password problem again. Two-factor has to be passed around, every change in the client's Google Ads change history carries the same name, and when somebody leaves the only way to cut them off is to change a password three other people use.

Tie each grant to one person instead. Each person gets one Workspace user, with 2-Step Verification enforced from the Admin console, and every client tool is reached through an invitation to that user:

• Google Ads: the client accepts a link request from your manager account, and your people reach the client's account through it.
• Google Analytics: the client adds the address under property access management, with the role the job needs.
• Search Console, Tag Manager and Merchant Center: each has its own user list in its settings, and each takes an email address.
• Google Business Profile: the client adds the address as a manager, which is why an organisation account for Business Profile is worth setting up once you have more than a handful.
• Drive: share the client's folder with the person, or with a Google Group of the people on that client, so a new hire is added in one place.

The client keeps ownership the whole time. The account, its billing and its recovery details are theirs, and so is the decision to remove you.

How it works: Bulk actions

The setting that blocks the first invitation

The first time a client sends an invitation, it often fails, and the client is not the problem. Workspace treats Google Ads, Analytics, Search Console and the other services outside Gmail, Drive and Calendar as additional Google services, and an admin can switch each one on or off per organisational unit. A new Workspace with conservative defaults may have them off. The user then cannot accept, or signs in and is told the service is not available for their account.

The fix is in the Admin console, under the apps section for additional Google services: turn on what your people need for the units that do client work. It is worth doing before the first client sends anything, because "your invitation didn't work" is a poor first week.

When someone leaves

Suspending the person's Workspace user blocks their sign-in, so every grant made to that address stops working at the same moment, at every client. Nobody has to change a client's password, and the client does not have to be told before it takes effect.

Two loose ends stay. The address is still on each client's user lists until someone removes it, and a suspended address there looks like a door left open to anyone reading the list. And their Drive files need a new owner before the account is deleted, which the Admin console does as part of deleting a user. We keep the removal as a line in the quarterly access check, and the rest of the leaving list is in what to do with a client's profile when the contract ends.

When a client issues their own account

Some clients will not invite an outside address. They create a user in their own Workspace, maria@acme.com, and their admin controls it: its password rules, its 2-Step Verification, how long its sessions last. That is a reasonable choice for them, and it gives Maria a second Google identity to keep apart from her first.

One browser handles two Google accounts with the account chooser, and the first one signed in is the default. A link from an email or a chat opens in whichever account the browser picks, so the Acme report gets opened, and sometimes edited, as the agency user, or a calendar invite is accepted from the wrong one. A new browser asking Google to "verify it's you" on every switch is the other common symptom (why Google asks on a new device).

That is where we use Mosaic. Maria keeps one profile for her agency account and one for each account a client has issued her. Each profile has its own cookies, so each stays signed in to one Google account and no chooser is involved. The setup key for each account's authenticator codes goes into that profile's credentials, so the code shows up in the window that needs it. Mosaic has no seats or shared profiles: each person on the team runs their own copy on their own computer, with the profiles for the accounts they hold.

For everything reached by invitation, one profile with the agency account is enough. Google's own tools already show Maria every client she was invited to, under one sign-in, and that is the setup to aim for.