docs(google-workspace): add gcloud commands and service account key permissions

[leet-c1]

What

Reworks the Google Workspace connector guide to follow the same shape as the Google Cloud project setup guide for the MCP servers: prerequisites up front, gcloud commands alongside every console procedure, and a symptom/cause/fix troubleshooting table.

It also closes two gaps that cost a real customer a full setup cycle: the service account key permissions needed to get a JSON key at all, and how to actually make Google Workspace the directory C1 creates users from.

Commit 1: Structure and gcloud

• Before you begin section listing the required Google Cloud, Workspace, and C1 roles.
• gcloud equivalents for project creation, API enablement, service account creation, key creation, key listing, and retrieving the numeric unique ID used for domain-wide delegation.
• New Allow service account key creation section covering both things that block key creation:
  • iam.serviceAccountKeys.create, granted by the Service Account Key Admin role
  • the constraints/iam.disableServiceAccountKeyCreation organization policy, enforced by default for organizations created on or after May 3, 2024, with the exact FAILED_PRECONDITION error, the gcloud org-policies describe --effective check, and the project-level exception YAML
  • constraints/iam.serviceAccountKeyExpiryHours, which silently breaks a working connector once a capped key lifetime elapses
• API clarifications: added service IDs and noted that the Admin SDK API covers Directory, Reports, and Data Transfer, so there's no separate Data Transfer API to enable despite the admin.datatransfer scope.
• Scope tables replacing the inline purpose lists, split into read-only and read/write tabs.

Commit 2: Using the connector as the C1 directory

The page explained how to connect the connector but never how to make Google Workspace the directory C1 creates users from — the most common reason to set it up.

• New Set Google Workspace as your C1 directory section covering the Directory > Directory sources flow, including that an app is selectable only after its first sync completes.
• States that a directory-only deployment needs neither the read/write scopes nor any Google Cloud IAM role.

Commit 3: Whole-document consistency pass

Reviewing the page end to end rather than section by section surfaced conflicts, including one introduced by commit 1:

• Contradiction fixed: the project overview called the Cloud Identity API optional while the API table listed it as required.
• Wrong role requirement fixed: the Google Cloud sections asked for a Google Workspace Super Admin. Those steps need Google Cloud permissions; the Workspace super admin is only required for domain-wide delegation.
• Duplicate guidance merged: two separate callouts told you to use read-only scopes if you aren't provisioning.
• Heading hierarchy fixed: What's next? was an H3 nested under connector configuration and forward-referenced a section below it. The directory step now precedes it and both sit at the same level.
• Replaced a vague "See below" in the troubleshooting table with a real link.

Please review: removal of the Editor role grant

The guide previously told users to grant the service account the Editor role. This replaces that with no project role at all.

The connector's access comes entirely from domain-wide delegation configured in the Admin console, so a Cloud IAM project role plays no part in authorizing Workspace API calls. Google's credential-creation docs confirm service account creation can be completed without any project role, and our own email provider guide already states "No project roles are required" for the identical pattern. The Editor instruction appears to have been carried over from the Google Cloud Platform connector guide, where project roles genuinely are required.

Worth knowing: Editor does include iam.serviceAccountKeys.create, so anyone following the old instructions got key creation as a side effect. With Editor removed, the key admin role is now called out explicitly rather than left implied.

If we'd rather keep the Editor guidance, that section is an isolated revert.

Verification

• MDX validated structurally: component tags balanced, code fences even, all internal anchors resolve, and the cross-page anchors into directory.mdx were checked against that file's actual headings.
• Google Cloud specifics (org policy name and default-enforcement date, error strings, permission and role IDs, gcloud syntax) verified against official Google Cloud documentation.
• Connector flags, scopes, and required APIs cross-checked against the connector's public README.
• Not run: a Mintlify build, so rendering is unverified beyond the structural checks.
• The unauthorized_client troubleshooting row reflects well-known domain-wide delegation behavior rather than a specific cited doc.

Notes

• directory.mdx is deliberately untouched; this PR only links to it.
• The ### Resources / ### Step 1-3 headings inside the self-hosted tab pollute the page outline, but that pattern is shared with other connector pages and is left alone here.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
conductorone	🟢 Ready	View Preview	Aug 14, 2026, 5:11 PM

[mindymo]

Looks good from a style perspective. Have these changes also been applied upstream in the baton repo?