Connecting client Gmail accounts to my scenarios without their password, a separate org per client, or meeting in person

Questions
,
1

:bullseye: What is your goal?

I run a small automation agency and manage all client scenarios from one Make organization on a single paid plan. My main product is an inbox automation: it watches the client’s Gmail, classifies emails with AI, applies Gmail labels, texts the owner about urgent ones, and sends out-of-hours auto-replies.

I need each client to connect their own Gmail account to my organization so I can use it in their scenario:

without them sharing their password with me
without creating a separate organization (and paid plan) for every client, which isn’t affordable at my scale
ideally remotely. I’ll meet in person if that’s the only option.

:thinking: What is the problem & what have you tried?

Credential requests: I created one through the API, but the link requires logging into my Make organization. From the help docs, sending requests to external people seems to be limited to Make partners and Enterprise customers, and the recipient still needs a Make account.
Inviting clients into my organization: as far as I understand, connections in a team are visible to all team members, so clients would see each other’s connections. Is there a role or setting that prevents this below the Teams plan?
Mailhook forwarding: this works for reading emails, but I lose the ability to apply labels and reply from the client’s own Gmail, which is the core of the product.
Separate organization per client: this works, but paying for a plan per client makes each client unprofitable at my pricing.
In person: they sign in on my laptop in a guest browser. This works, but it doesn’t scale and isn’t practical for every client.

:clipboard: Error messages or input/output bundles

My questions:

Is there a way for a client to authorize a Gmail connection into my organization remotely, without seeing other clients’ data?
If I invite a client as a restricted role, can they create a connection without seeing my other connections and scenarios?
How do other agencies handle this without charging clients for their own Make plan?

Thanks!

3

I wouldn’t compromise the tenant boundary just to avoid one extra Make account. If the client’s Gmail connection lives in a shared org, you need to be completely sure other clients can’t see or touch that connection.

The cleanest model is usually client-owned org/account + they authorize Gmail + they invite you to maintain the scenarios. If that makes the offer unprofitable, I’d treat the Make cost as part of the product pricing rather than centralize client credentials.

A custom OAuth flow + direct Gmail API can remove the Make UI from authorization, but then you own refresh-token storage, revocation, scope control and security. That’s a real product/security surface, not a free shortcut.

4

One trap to know before you scale this: for personal @gmail.com addresses Make needs your own OAuth client from Google Cloud, and as long as that app’s consent screen is in Testing mode, Google lets the refresh tokens expire after 7 days. Every client connection would then break once a week. Publishing the app to Production fixes the expiry, but Gmail scopes are restricted, so without Google’s verification your clients see an “unverified app” warning and the app is capped at 100 users, which matters for an agency model.

On the visibility question I’m with clearmerit: one org holding every client’s inbox connection is the part I’d avoid, one mistake there exposes all of them.

5

There’s a workable middle path between “one messy org” and “paid plan per client”: one org + one team per client, and the client authorizes the connection themselves with their own Google login.

The key mechanic: when someone adds a Gmail connection in Make, the OAuth consent screen opens in their browser and they sign into their own Google account. You never see or touch their password. So the remote flow is:

  1. Create one team per client inside your org. Add the client as a team member with a restricted role. They only see scenarios and connections inside their own team — this answers your visibility question.
  2. Have them open Connections inside their team and add Gmail themselves. Walk them through it on a 5-minute video call or send a short screen recording of the clicks.
  3. Once the connection is live, you build scenarios against it. You can downgrade or remove their role afterwards if you want.

This is exactly how I onboard client inboxes without paying for per-client plans. Two caveats:

  • Goran’s point about personal @gmail.com addresses is real — for those you’ll need your own Google OAuth client configured in the Google Cloud Console first (Make help center has a walkthrough).
  • Tell clients upfront that Google can expire the refresh token (long inactivity, security flags), so scenarios can fail silently if nobody reconnects. I send every client a short “reconnect your Gmail” checklist at onboarding so it’s not a surprise.

The one thing I wouldn’t do: put every client’s Gmail connection in one visible pool. Teams keep you honest when a client asks “who can see my emails?”