Workspace OU Policy Map
Google Workspace governance
Built a read-only governance dashboard that makes Google Workspace OU structure and policy differences easier to review.
The problem
Google Workspace policy state lives per organizational unit, layered by inheritance. In a deep OU tree it becomes genuinely hard to answer basic governance questions: which settings does this OU actually get? Which of its overrides are redundant? Which two OUs are configured identically and could merge?
The Admin console shows one OU at a time. Reviewing a whole hierarchy — or proposing a restructure — needs the effective policy state of every OU, side by side, with the inheritance made explicit.
The approach
The dashboard is a Google Apps Script web app that syncs the OU tree, users and retrievable policies into a Google Sheet acting as the system of record, then serves an interactive tree, per-OU policy views, side-by-side comparison and structural findings from that snapshot — never calling Google APIs on page load.
It is read-only in depth, not just by promise: every OAuth scope is .readonly, every capability row declares writeSupport: false, the execute control is permanently disabled, and a test asserts that no connector may expose writes. “Changes” exist only as dry-run simulations and reviewable drafts.
My role — Sole builder: data model, resumable sync design and the review interface.
How it works, step by step
From tenant APIs to a reviewable policy map
The implemented pipeline. All example OU names and figures on this page are fictional.
01Start a read-only sync
The admin kicks off a background inventory of the tenant. Nothing about this app can write to Workspace — by scopes, not just by intention.
Select any node in the diagram to inspect it.
- Person
- This project
- Internal layer
- Connected system
- Data at rest
- Info
Explore the model
Policy state — Employees
Proposed change — review only
Remove the override on Workspace service policy: it re-states the value already inherited from Organization. Flagged for human review — this tool has no apply action.
Fictional demo data and generic OU names. Rows marked “Manual review” have no verified read API — the real tool says so rather than guessing. Read-only by design: no “Apply changes” exists anywhere in the implementation.
Architecture
Architecture
Page loads never touch Google APIs — the UI reads the Sheet snapshot; only the background sync talks to Google.
- Person
- This project
- Internal layer
- Data at rest
- Connected system
- Person
- This project
- Internal layer
- Data at rest
- Connected system
Zero runtime dependencies: the frontend is hand-rolled vanilla JS over Apps Script HTML Service, with a skip link, focus containment and ARIA throughout. A small Node test harness (30 assertions) loads the server files and asserts fingerprint stability, OU path-boundary correctness and the read-only invariant.
Key engineering decisions
- OU hierarchy
- Policy-state inspection
- Enabled/disabled comparison
- Structure review
Switch to the technical view for the engineering trade-offs behind these.
Challenges & limitations
- Chrome policy coverage is exactly the chrome.users.* and chrome.devices.* namespaces; broader Workspace settings appear only as the Cloud Identity Policy API returns them for a given tenant — anything else is explicitly marked for manual review.
- Read-only by design: there is no apply-changes workflow at all. Proposed structures, dry-run moves and change plans are review artifacts for a human.
- Built and deployable, with a clearly-labeled fictional demo snapshot for preview; this page makes no claims about live-tenant results.
- No Groups API integration — group-targeted policies are shown from the policy data itself.
What I learned
Governance tooling earns trust through what it refuses to do: refuse to write, refuse to guess unsupported settings, refuse to compare OUs by anything but their actual effective configuration. The read-only constraint wasn’t a limitation of this project — it was the product.
Project status
Complete Apps Script implementation with a resumable sync engine, fingerprint analysis, comparison UI and a labeled demo snapshot; deployable via clasp. Shown with generic OU names and fictional figures only.