Not every client group's tenant is Microsoft.
The Microsoft 365 lane gets most of the attention on a site like this one, because most client groups run it. Some do not. This page writes the same lane structure — request families, an exception path, a named owner — for the client groups whose actual tenant is Google Workspace.
What enters the Workspace administration lane.
Useful when a client group's book runs on Google Workspace, and the current lane definition only actually describes Microsoft 365.
User, group, and organizational-unit administration — creation, changes, and removal against an approved profile — license and edition assignment across the Workspace domain, shared-drive permission and membership administration, and 2-Step Verification and admin-console security-setting upkeep against an agreed baseline.
An authorized change is completed and logged against the documented standard, the same way a Microsoft 365 change is, or it returns as an exception naming the policy or licensing question involved.
The named Workspace domain and administrative access method, the authorized-requester list, the approved edition and licensing model, and the admin-console security baseline actually in force.
Where the two platforms line up, and where they do not.
Naming the parity avoids a lane definition that quietly assumes Microsoft wording for a Google tenant.
- User and license administration
- Functionally the same request family as the Microsoft 365 lane, run against Workspace's own admin console instead.
- Shared drives versus SharePoint sites
- Cover similar ground, but permission models and defaults differ enough to need their own written baseline — see the mirrored collaboration lane.
- 2-Step Verification versus Conditional Access
- Both are identity-security controls; Workspace's options are structured differently and should not be assumed to match Microsoft's baseline one for one.
- Third-party app connections
- Reviewed against Workspace's own marketplace and admin controls, following the same approval pattern as an SSO connection on the Microsoft side.
Who owns what in a Workspace client group.
| Domain ownership and billing relationship | Confirmed at intake — practice or client, never assumed by delivery. |
|---|---|
| Approved administrative routines | Delivery executes against the agreed baseline for the Workspace console. |
| Security-setting and 2-Step Verification changes | Named owner approves anything that changes the standard itself. |
| Edition, licensing, and cost changes | Selling practice approves; delivery administers what is assigned. |
Ask these before assuming a Workspace client group is covered by the same lane.
- Does the written lane actually name Workspace, or does it just say "Microsoft 365" by habit?A lane written for one platform does not automatically cover the other.
- Who administers the domain today, and how is that access transferred?Confirm the admin-console access path before assuming it matches the Microsoft 365 handoff.
- Are shared-drive permissions reviewed on the same cadence SharePoint would be?Borrowing the pattern is fine; skipping the review is not.
- Does the client group actually run a mix of both platforms?A merger or acquisition can leave one client group on two identity systems at once — name both instead of picking one.
See the equivalent lane on the Microsoft side.
The mechanics are deliberately parallel — Microsoft 365 administration and Teams/SharePoint hygiene both follow the same written-lane pattern applied here to Workspace.