Every Google Workspace admin action already exists in the Admin console. That's exactly why "Workspace automation" tools that just give you the same buttons in a different interface are worthless: clicking "suspend user" in a new tool instead of Google's console is a console swap, not automation. Real automation means nobody clicks at all: HR marks someone terminated, and the entire offboarding sequence runs itself. This article is about that difference: what the manual way actually costs, why Google's native options don't close the gap, and the fifty-plus actions that become possible once events, not humans, do the triggering.
How Workspace Admin Work Runs Today, and What It Quietly Costs
Start with an honest picture of the current way, because the value of automation is exactly the size of what's broken without it. In most companies, Google Workspace administration runs on a simple loop: something happens to a person, someone files or forwards a ticket, and an IT admin executes a sequence of console clicks from memory or from a checklist doc that was last updated two admins ago.
Each individual click is trivial. The failure is in the loop itself, and it fails in five specific, expensive ways: a lag between event and response, steps that get skipped under pressure, process knowledge trapped in one person's head, no record of what actually ran, and a constant tax on IT's attention. Here's each one in the detail that makes it expensive.
The lag. The event and the response are separated by a ticket queue. A new hire's account exists when IT gets to the ticket, not when HR completed the record, so day one becomes day three. Worse in the other direction: a termination processed by HR on Friday reaches the console on Monday, and for that weekend, a departed employee's sessions, tokens, and Drive access are all live. Offboarding lag is not an inconvenience; it is standing security exposure with a duration measured by your ticket queue.
The skipped step. A departure done right is a dozen actions in a specific order: sessions, tokens, devices, aliases, data transfer, forwarding, license, archive. Nothing in the console enforces the sequence or checks completeness, so every manual offboarding is a dozen chances to skip one. The skips are invisible on the day and expensive later: the license that bills for a year after the person left, the OAuth token that outlives the password reset, the suspended account quietly consuming a paid seat (suspension does not stop billing).
The tribal knowledge. The branching logic (which groups for which department, which license tier for which role, which org unit, or OU, for which location) lives in the heads of whoever does this most often. An OU is Workspace's way of grouping accounts so that a whole set of policies (password rules, app access, security settings) applies to everyone in it at once; which OU an account lands in decides which rules it lives under. That mapping, undocumented, is exactly the kind of knowledge that walks out the door. When the person who knows it is on leave, onboarding quality drops. When they resign, the process resigns with them.
The missing record. When an auditor asks "show me this person's offboarding," a console-driven process answers with archaeology: scattered admin audit events, a closed ticket that says "done," and no artifact proving every step ran. Access reviews and compliance audits inherit that gap.
The interrupt tax. All of it lands on IT as interrupt work: high-frequency, low-judgment tasks that fragment the day and crowd out the projects that actually need an engineer's brain.
Put a shape on it: multiply your monthly joiners, movers, and leavers by a dozen actions each, add the security exposure of every offboarding delayed by a queue, and add one audit season of reconstructing what ran. That's the bill for running Workspace by hand. It gets bigger every quarter your headcount does.
The Fix Is Not a Better Console. It's Removing the Human Trigger.
Here is the core of this entire article, so let's not bury it: the value of Workspace automation is not the actions. It's that nobody clicks them. If a tool hands you the same fifty actions behind different buttons and a human still executes them ticket by ticket, nothing above gets fixed; you've just moved the manual work to a new tab. Every problem in the previous section traces to one root: a human is the trigger. Fix that, and the rest follows. Zluri fixes exactly that, through three layers.
Event Triggers: The Alert That Fires the Playbook, Not a Human
Zluri's workflows listen for the events that should cause admin work: the HRMS record that marks a joiner, mover, or leaver, the approved access request, the security signal. The HRMS termination event fires the complete leaver playbook by itself, the moment HR saves the record, not when a ticket gets picked up. The start-date record fires the joiner playbook before day one. (This is what the Zluri and HRMS integration actually watches for.)
"Trigger" is easiest to see under pressure, so walk through the security case concretely:
The signal. It doesn't come from Zluri; it comes from wherever your security stack already watches for it, Google Workspace's own Alert Center flagging a suspicious login, an IdP like Okta surfacing a risk score, or a connected SIEM or XDR catching a pattern. Say one fires at 2 AM: an impossible-location login, or a sudden burst of Drive downloads.
The manual response. The alert sits in a queue until someone on call opens their laptop, reads it, decides it's real, and starts clicking through session sign-out, password reset, and token revocation by hand. Several minutes lost before the first action even runs.
The triggered response. That same alert is the trigger. Zluri receives it via webhook or API and fires the containment playbook itself, so sessions are already killed and tokens already revoked by the time the on-call engineer opens the alert to investigate.
The safeguard. This isn't "any alert nukes any account" with no human ever weighing in; an accidentally locked-out genuine employee at 2 AM is a real cost too. The judgment call happens upstream, when the playbook is configured, not downstream while the clock is running. A team sets the risk threshold in advance: signals above a defined severity auto-execute containment, because the cost of hesitating exceeds the cost of a false positive; lower-confidence signals route to an approval step instead. Every action is logged and reversible, so a mistaken auto-containment gets corrected in minutes, not carried for days. Zluri isn't deciding the login was suspicious, and it isn't making the containment call unsupervised either; the team already made that call when it set the policy. What Zluri removes is the minutes it used to take a human to notice, decide, and click, not the human's control over what counts as dangerous enough to act on immediately.
Across all of these, the human's role shifts from executing sequences to, at most, approving them where judgment genuinely matters.
No-Code Rules: One Playbook, Every Person Routed Correctly
A console applies the same clicks to everyone; one playbook can't serve the whole company unless something inside it knows how to treat different people differently. That's what rules do: take a single field from the HRMS record and use it to decide which specific action fires. In the same joiner playbook:
One playbook, four fields, every new hire routed correctly without anyone hand-picking their groups. That branching logic is exactly the tribal knowledge from the problem section, moved out of someone's head and into rules that anyone who owns the process can read and edit in a visual builder, no code, no API knowledge. (Google's own Apps Script and Admin SDK can automate pieces of this, but they are code: someone writes them, someone maintains them, and they break silently when that someone leaves. SCIM provisioning helps too, but it syncs accounts, not events; it still can't tell you a termination just happened.)
Cross-System Scope: What "Complete" Actually Means
The deepest limit of doing this inside Google: a departure is not a Google event. It's a company event that touches Google and Slack and Salesforce and the MDM and forty other apps. Native Workspace automation ends at Google's walls.
It's also worth being precise about what "complete offboarding" means, because the narrow version of that claim (we automate the apps you've connected to us) isn't the interesting one. Most companies' real exposure sits outside it:
That third tier is where most identity risk actually hides: every app an employee actually used, federated or not, sanctioned or not, becomes part of their known footprint. That discovery runs across eight independent methods, not SSO alone, and because that discovered footprint feeds the same offboarding workflow that runs the actions in this catalog, the leaver playbook isn't bounded by "the apps we have a button for." This is why Zluri plus Google Workspace works as a complete identity and access management stack: Workspace stays the system of record, Zluri becomes the system of automation around it, for what's connected and for what was merely discovered.
The Manual Way vs. the Triggered Way
And the audit row deserves one extra sentence: when the auditor asks for a specific person's offboarding, a console history is archaeology and a playbook run is a document.
What Becomes Possible: The Full Action Catalog
With triggers and rules in place, the question flips from "who will do all this?" to "what should the event fire?"What follows is every Google Workspace action Zluri can execute, organized not alphabetically but by the moment it matters. Each section is a scenario, the table lists the actions it uses, and the point throughout is that these compose: actions chain into playbooks, playbooks fire on events.
Day One: The Joiner Playbook
The goal: the person is fully productive at 9 AM on day one, and IT did nothing manually, the same promise behind zero-touch provisioning generally, applied here to Workspace specifically. The trigger is the HRMS record; the specifics (groups, org unit, license tier, role) resolve from department and designation.
Sequencing matters: org unit placement early means the account inherits the right security policies from its first second, and license assignment drawing from the reclaimed pool keeps onboarding from silently inflating the contract.
Profile Completeness: The Enrichment Set
A Workspace account with an empty profile creates friction everywhere downstream: directory lookups fail, HR data diverges, device assignment has no anchor. These actions keep the directory record complete, typically running as the tail of the joiner playbook or whenever the HRMS record changes.
Two of these are load-bearing. External ID is what lets every other system agree on who this person is; setting it at creation prevents identity-matching pain in audits and integrations later. And the relation (manager) field is what offboarding data transfers and approval routing resolve their targets from, so keeping it current is what lets those workflows run unattended.
Role Changes: The Mover Playbook
Movers are where manual processes fail most expensively, and not by accident: a role change has two halves and manual work reliably does only one, new access gets granted, old access quietly survives. Run enough role changes that way and employees accumulate the union of every role they've ever held.
The design principle: a mover event triggers grant-new and revoke-old in one workflow, on one trigger, so revocation is not a separate task anyone can forget. "Activate user" belongs here for a reason people don't expect: leaves of absence are movers too, and suspend-on-leave plus activate-on-return as paired workflows keeps dormant-but-live accounts from accumulating.
Last Day: The Leaver Playbook
Offboarding is a race between revocation and risk. The leaver playbook makes the ending complete, ordered, and identical every time, triggered by the HRMS termination event.
The ordering encodes hard-won lessons. Sessions and tokens die first, because they are the live access. Suspension comes before deletion, holding the account frozen while data continuity runs. License revocation is its own explicit step because suspended users still consume paid licenses, one specific, common way an orphaned account keeps costing money long after it stops being used. Deletion runs last, gated on data transfer confirming, so security speed never costs the company its data.
What the Company Keeps: The Data Continuity Set
The reason offboarding gets delayed in practice is almost never the access; it is the data. These actions solve exactly that, which is what lets the leaver playbook run same-day instead of waiting weeks "just in case."
The email forwarding action's mechanics are cleverer than the name suggests: the user's address changes (abc@ becomes offboard_abc@), and the original abc@ is reborn as a group whose members receive everything sent to it. The account is fully offboarded, the address lives on, multiple people can cover it.
When Something Is Wrong: The Security Response Set
Security incidents are Workspace admin actions on a deadline: a compromised credential is only as dangerous as the time it stays usable. These actions chain into response playbooks triggered by security events, executing in minutes rather than being assembled from console memory mid-incident.
Read as a set, these cover the account-takeover kill chain: session, credential, tokens, second factor, recovery channels, device. The recovery-channel actions are the ones manual responses most often miss; an attacker who swapped the recovery phone regains the account after the password reset unless that channel is stripped too.
The Standing Layer: Groups, Aliases, and Org Administration
Between lifecycle events sits the routine administration that keeps the directory structured; less dramatic, equally automatable, and worth automating precisely because these are the tasks that interrupt deeper work all day.
Three Playbooks Worth Building First
For teams starting from zero, sequence the wins.
First, the leaver playbook with data continuity: it removes the most risk and the most fear, and it is the workflow auditors ask about. Second, the joiner playbook: highest volume, most visible to the business, the one that turns onboarding from a ticket queue into a non-event. Third, the security response playbook: lowest frequency, highest value-per-run, and the one you want to exist before the day you need it.
Movers and the standing layer follow naturally, at which point Google Workspace administration has quietly stopped being a job and become a property of the system. For the full picture of how these four playbooks fit into the wider joiner-mover-leaver arc across every app, not just Workspace, see our complete guide to joiners, movers, and leavers.
Frequently Asked Questions
Why use Zluri instead of automating in the Google Admin console or Apps Script?
The console requires a human to execute every step, and Apps Script requires someone to write and maintain code that still only reaches Google. Zluri adds the three things neither provides: event triggers (HRMS, access requests, security signals) that fire workflows without a human, no-code rules that branch each playbook per role and department, and reach across 300+ apps beyond Workspace in the same run.
Does offboarding automation only cover apps directly connected to Zluri?
No. Directly integrated apps (300+, including Google Workspace) get the deep, native action automation shown in this catalog. Apps discovered through Zluri's broader discovery methods, including shadow IT that was never federated through SSO or centrally approved, are still part of the employee's known footprint and are carried into the same offboarding workflow, instead of staying invisible or requiring a manual, app-by-app chase.
What actually goes wrong with manual Google Workspace administration?
Five recurring failures: response lag behind ticket queues (including days of live access for departed employees), skipped steps in multi-action sequences, process logic trapped in individual admins' heads, no complete audit record of what ran, and constant interrupt work consuming IT time. Each traces to the same root: a human is the trigger.
What Google Workspace actions can Zluri automate?
Over fifty admin actions across the full lifecycle: user creation and licensing, group and org unit management, profile enrichment, suspension, session and token revocation, device actions including remote wipe, data transfers, email forwarding, security responses like 2FA reset and recovery-channel removal, and account archival or deletion.
How are Google Workspace workflows triggered in Zluri?
By events rather than tickets: HRMS joiner, mover, and leaver events, approved access requests, and security signals can each trigger a playbook, which then executes its action sequence automatically and logs every step.
Does suspending a Google Workspace user stop the license billing?
No. Suspension freezes access but keeps the license assigned and billed. That is why license revocation is a distinct step in the leaver playbook, returning the seat to the pool the day the person leaves. For the wider set of ways Workspace licenses leak money beyond offboarding, see our guide to optimizing Google Workspace licenses.
How does Zluri handle a departing employee's email and files?
Through dedicated data continuity actions: Drive and application data transfers to a designated user (typically the manager), and an email forwarding mechanism that recreates the departing address as a group so inbound mail reaches the right colleagues without the account staying alive.
.svg)
