What the integration does
One-click fleet import
Pulls every ChromeOS device from your Google Workspace customer. Serial, model, OU, assigned user.
Read-only by default
Service account with the minimum ChromeOS read scope. Write-back is opt-in, per district, off by default.
Stays in sync
Re-run the sync any time. We match on serial number, so existing HQ devices update in place. No duplicates.
How it works
- 1
In Google Cloud, create a service account and grant domain-wide delegation for admin.directory.device.chromeos.readonly.
- 2
In KBS HQ, open Integrations, paste the service account JSON, your customer ID, and a super-admin email to impersonate.
- 3
We verify the connection live and pull a sample device. If it works, we save the credentials encrypted.
- 4
Click Sync devices. Your fleet appears in the Devices tab, matched by serial. Run sync again whenever your roster changes.
Why this matters
No more CSV onboarding
Most coverage vendors ask for a 4,000-row CSV every August. We ask for a Google Admin connection, one time, and the roster takes care of itself.
Claims link to real devices
When a parent files a claim, the device record is already there. Your techs see the same serial, assigned user, and OU that Google Admin shows. No reconciliation work.
Why Google Admin is the right starting point for Chromebook coverage
If your district runs ChromeOS, Google Admin Console is already the system of record for every Chromebook you have ever enrolled. Serial numbers, model identifiers, organizational units, assigned users, last sync time, enrollment status. Every coverage program that does not plug into that record is asking your IT team to maintain a parallel inventory in a spreadsheet. That parallel inventory is wrong within a week, and it is wrong on the worst possible day, the day a parent files a claim and the device record cannot be found.
KBS HQ takes a different approach. We treat Google Admin as the spine of your Chromebook program and build coverage, parent enrollment, claim intake, and repair workflow on top of it. The integration uses a Google Cloud service account with domain wide delegation and the narrowest possible ChromeOS scope. We pull the data we need, we never modify your fleet, and we keep everything aligned the moment your roster changes.
That alignment matters at every stage of the school year. When you image 1,200 new Chromebooks in August, they show up in KBS HQ on the next sync. When a building changes OU structure mid year, parent enrollment offers route to the right school. When a device is decommissioned, the coverage closes cleanly. No CSV uploads, no duplicate inventories, no end of year reconciliation panic.
CSV onboarding vs Google Admin sync
Most K-12 coverage vendors still require a roster upload every fall. Here is what changes when the same program runs on a live Google Admin connection instead.
| Task | CSV onboarding | KBS HQ + Google Admin |
|---|---|---|
| Initial fleet load | Export, scrub, upload, fix errors | One click, fleet appears in minutes |
| New device rollout | Manual re-upload per batch | Next sync picks them up automatically |
| OU or building changes | Vendor never knows | Reflected on the next sync |
| Decommissioned devices | Stale records linger | Status flips, coverage closes |
| Claim lookup | Match by hand against Google Admin | Already linked by serial |
Built for K-12 technology directors
The Google Admin integration was designed around the workflows that show up in real K-12 IT shops, not generic asset management. A few of the scenarios it solves on day one:
1:1 Chromebook districts
Every student device tied to coverage and parent enrollment without manual roster maintenance.
Hybrid Chromebook plus iPad fleets
Pair the Google Admin sync with Jamf Pro for a single coverage program across both platforms.
Summer refresh cycles
Image new Chromebooks in Google Admin and they appear in KBS HQ ready for fall enrollment.
Multi building districts
OU paths flow through so building leadership and reporting stay scoped correctly.
Security and scope, in plain language
Minimum scope only
admin.directory.device.chromeos.readonly is all we ask for. Write back, if you ever enable it, is a separate scope and limited to disable or re-enable a single device tied to a claim.
Encrypted credentials
The service account JSON is encrypted at rest with AES 256 GCM. It is never returned to a browser and never written to logs. Rotating the key in Google Cloud rotates it everywhere instantly.
Reversible
Disconnect the integration from the KBS HQ Integrations page at any time. Credentials are wiped. Your device records stay in HQ, your Google Admin is untouched.
Related resources
Frequently asked questions
What does the Google Admin integration actually sync?+
Every ChromeOS device under your Workspace customer ID. Serial number, model, assigned user, OU path, and status. KBS HQ matches by serial number so existing device records stay linked, no duplicates.
What permissions does it need?+
A service account with domain-wide delegation for admin.directory.device.chromeos.readonly. Read only. We never modify devices in Google Admin unless you turn write-back on, and even then it is limited to disable or re-enable actions tied to a claim.
How often does it sync?+
On demand from the Integrations page in HQ. Scheduled hourly sync is on the roadmap. Most districts run it after their summer refresh and after any large enrollment event.
What if a device is already in HQ from a CSV import?+
We match on serial number and update the existing record with anything new from Google Admin. Nothing is deleted or duplicated.
Does this replace our Google Admin Console?+
No. Google Admin stays the source of truth for the device. KBS HQ adds the coverage, claim, repair, and parent enrollment layer on top, and keeps both views in sync.