Lifecycle Management

Joiners and leavers, step by approved step.

Lifecycle Management turns offboarding and onboarding checklists into playbooks: assigned to users by org unit or custom-schema field, started from a candidates inbox, with every destructive step proposed for approval and one evidence pack per run.

What it does

A playbook is an ordered list of steps with a direction — onboarding or offboarding — and an assignment rule. Assignment reuses the rule engine behind Group Management: match by org unit, or by custom-schema fields such as an employment status your HR tooling maintains, and several playbooks per direction are allowed. When a user could match more than one playbook, resolution is deterministic — the most specific rule wins, then an explicit precedence you set — and a conflict preview shows the overlaps before you save.

Detection watches directory state: an org-unit move, a suspension that flips, a leaver date arriving in a custom-schema field you point it at. A user who matches lands in the candidates inbox with the resolved playbook and the signal that fired it — nothing runs until a person starts it. Each destructive step in the run — suspending the account, the org-unit move, group and license changes, revoking tokens, app passwords or mail delegation, the transfer — is proposed for approval in the same gate every Geeplo change goes through. The run records who proposed, who approved, and what each step changed, as one evidence pack.

Who it's for

The in-house admin who wears the HR handover, IT and compliance hats: move a user to the leaver org unit or set a leaver field, and the right playbook appears as a reviewable candidate — approve the steps, hand HR or legal one evidence pack. The MSP operator running standardized runbooks per customer: define playbooks per tenant from the same step library and see candidates and runs across their managed tenants, without holding customer super-admin Google scopes. The fractional admin with little context per visit: the candidates inbox says who is joining or leaving and which signal said so, and a run's timeline picks up mid-flight with per-step evidence of what already happened.

How do you offboard a user in Google Workspace?

Google's own answer is a human checklist: hand over the files the leaver owns, suspend the account before anything destructive, revoke the credentials and access they accumulated, reset two-step verification as an admin, hand the mailbox over, reclaim the license last. It is the right order, and the offboarding guide walks it step by step. The cost is not the first leaver — it is the tenth, when the checklist lives in one person's head and the evidence lives nowhere. Lifecycle Management turns that checklist into a playbook: the same steps, assigned by rule, started from a candidates inbox, proposed for approval step by step, with the run's evidence pack at the end.

Does anything run without a person approving it?

No. Detection can notice a leaver on its own — that is what the candidates inbox is for — but a run starts when a person starts it, and no destructive step executes unattended. Every step that changes something real — suspend, the org-unit move, custom-schema writes, group removal, license removal, token and app-password revocation, mail-delegation revocation, a transfer — materializes a proposal that waits for approval before it reaches Google. The exceptions are narrow and visible: a playbook may auto-commit individual non-destructive steps — granting mail delegation, setting a vacation responder, sending a notification — and that policy is set per step, shown in the UI. There is no offboard-while-you-sleep mode.

What can a playbook step do?

The v1 step library covers the Directory, Gmail settings and licensing: suspend or unsuspend an account, move it between org units, write the custom-schema fields your process uses, reset a password, add or remove group membership, grant or revoke mail delegation, set a vacation responder or a send-as address, set auto-forwarding — gated to destinations in your own organization, with what happens to the mail explicit and defaulting to keeping it — assign or remove a license, revoke a third-party app's token or an app password, and compose transfer jobs from the Transfer Tool's registry — a leaver's Drive to a successor, secondary calendars to their manager — sequenced in the order the registry defines.

What it deliberately leaves out: deleting the user. Suspension is the terminal state a v1 playbook reaches — reversible while the handover is verified — and deletion stays with you, a manual super-admin action in the Admin console.

How it works

1. Assign the playbooks. Write onboarding and offboarding playbooks as ordered step lists and assign them with the rule engine — by org unit, by custom-schema field, or both. A conflict preview shows which users would match more than one playbook before you save.
2. Start from the candidates inbox. Detection watches directory state — org-unit moves, suspension changes, the leaver field you configure — and files each match with its resolved playbook and firing signal. Start a run, or dismiss or snooze the candidate. Nothing runs by itself.
3. Approve the steps. Before anything is proposed, preflight checks run — the target account is active, the source is not on litigation hold, the transfer destination is not suspended — and a run that fails them blocks. Then each destructive step waits for an approval; non-destructive steps follow the per-step policy the playbook sets.
4. Hand over the pack. The run's evidence pack records who proposed and approved each step, the request and result of each Google call, and the before and after state — viewable as a timeline, exportable for HR or legal. Destructive runs also carry an undo plan and a verification reminder, and an interrupted run resumes where it stopped without repeating a step.

What it doesn't do (yet)

Lifecycle Management does not create accounts: onboarding playbooks complete accounts that already exist — org-unit placement, license assignment checked against available seats, group adds, delegation and custom-schema setup, a welcome notification, and a propagation check recorded in the pack — because account creation stays where it is today, in the Admin console. It does not delete users, as above. It has no HR-system connectors: HR dates reach it as read-only custom-schema attributes that you or your tooling maintain. Mobile-device wipe is not a v1 step. And detection never escalates to execution on its own: a filed candidate is a proposal, and people dispose of it.

What access it needs

Detection reads directory state — org units, suspension flags, the custom-schema fields you point it at — through the admin directory read scopes the scopes page already lists. Writes are different: they are executed by the same component that executes every approved Geeplo change, and only after a person approves. Every scope Geeplo's service account holds, which module uses it and why, and how to remove the access entirely in Domain-wide delegation, are on the scopes page.

Related modules

Group Management (the rule engine that assigns playbooks is the same one behind its dynamic rules), Service Accounts (the shared and robot accounts a leaver often ran), ConfigShield (an inactive-account finding can file an offboarding candidate), ShareGuard (review what the leaver shared before the account goes), the Transfer Tool (the transfer your playbook composes is its registry at work), and the modules hub for the rest. The DataScout, Teams, Requests, Approval Gate and Assets Revalidation pages are not up yet.