Google Workspace Admin
Connect your customers' Google Workspace tenants so your product can manage users, groups, and devices through the Admin SDK. The customer's super-admin consents on Google's screen once, and Askel handles token refresh from there.
What you can do
List and read user profiles in the directory
Fetch name, email, org unit, department, and account suspension status for any user in the customer's Workspace tenant. Useful for seeding onboarding profiles or verifying that an expected user exists before provisioning.
Create and update user accounts
Provision new Workspace users or update existing profile fields such as org unit, job title, and phone number as part of an automated onboarding or lifecycle workflow.
Manage group memberships
Add or remove users from Google Groups, and read the current member list for any group. Drive access decisions in your product based on the customer's existing group structure.
Read organisational units
Fetch the customer's OU hierarchy so your product can scope provisioning to the correct branch of the org tree without the admin having to type OU paths manually.
Inspect enrolled devices
Read managed Chromebooks and mobile devices enrolled in the customer's domain, including device name, last sync time, OS version, and policy compliance state.
Audit admin log events
Fetch Admin SDK Reports API events for login, account changes, and group modifications so your product can maintain an audit trail of directory activity without asking the customer to export logs.
Auto-provisioning new hires into your product's workspace
You sell a B2B knowledge management platform. A new customer, Alderton Media Group, manages 450 staff in Google Workspace. Every new hire needs a Workspace account, an account in your platform, and membership in the relevant department Google Group within their first day. Today an IT admin does all three steps by hand.
- 1
Super-admin consents
Alderton's Workspace super-admin clicks Connect Google Workspace Admin in your product. Askel redirects to Google's consent screen listing the Admin SDK scopes requested. The admin approves and Google issues a refresh token.
- 2
OU and group discovery
Askel reads Alderton's OU tree and group list. Your product's onboarding wizard shows them and the admin maps each department OU to a matching group and platform role. The mapping is saved.
- 3
HR system triggers a new-hire event
When Alderton's HR system (connected separately) creates a new employee record, your product receives the event and calls Askel to create a Workspace user in the correct OU.
- 4
Group assignment
Askel adds the new user to the department Google Group matching the employee's department field. Existing Google Group settings propagate app access and distribution list membership automatically.
- 5
Platform account created
Your product creates the user's platform account and marks the onboarding milestone complete. Alderton's IT admin no longer needs to touch the process for standard new hires.
OAuth 2.0
The customer's Google Workspace super-admin consents on Google's standard OAuth screen. Askel requests the Admin SDK Directory and Reports API scopes needed for the configured workflow. Only the refresh token is stored; access tokens are minted per request using Google's token endpoint. No service account JSON file is created or transferred.
How Askel sits between your product and the customer's system
FAQ for Google Workspace Admin
Does the connecting user have to be a super-admin?+
What Admin SDK scopes does Askel request?+
Does this work for Google Workspace for Education?+
What happens if the super-admin who consented leaves the organisation?+
catching drift before it breaks, and hitting go-live dates.
© 2025 Askel.ai. All rights reserved.