Service Accounts
Shared and robot accounts, each owned by a team.
Workspace user accounts used by systems and shared functions, not Google Cloud IAM service accounts, in one register where every row has a team and an owner.
Read the video as text
- Every Workspace has accounts that belong to no one person.
- Sync bots, mail relays, export jobs.
- Geeplo keeps these shared and robot user accounts in one register.
- Not Google Cloud service accounts: real Workspace user accounts, used by systems and shared functions.
- Every row has a team and an owner, so the question of who runs it always has an answer.
- Suspend an account without deleting it, and bring it back when you need it.
- Reset a password, and the new one appears once, on your screen, never stored anywhere.
- Record who can send mail as the account, and with which scopes.
- No dormancy alerts: an old date is just a date, and the judgement stays yours.
- Shared accounts, owned like everything else.
What it does
The register lists your shared and robot user accounts with their display name, status, owning team, owner, alias count, delegation count and last update. Every account belongs to a team, so the question “who runs this thing” has an answer on the row itself; teams can be reassigned one by one or in bulk. Three actions cover the risky middle of an account's life. Suspend stops an account without deleting it, and unsuspend brings it back. Password reset issues a new password through the Admin SDK, shows it once and never stores it, and requires the tenant's service-account admin role. Mail delegation records who may send from the account and with which scopes. Aliases can be attached, with restricted names held for extra approval. The register exports to CSV or JSON for offboarding checks.
Who it's for
Platform teams who own the sync bots and mail relays everyone depends on. Security admins who need to say, per account, who owns it and when it last changed. Anyone preparing an audit where shared accounts are the first question.
How it works
- Register. Rows show email, display name, status, team, owner, aliases, delegations and updated date, sortable per column.
- Assign ownership. Set the owning team and owner per account, or change teams in bulk.
- Suspend and restore. Suspend halts the account; unsuspend reverses it.
- Reset a password. The new password appears once in the response and is never written to any local table, audit row or log line.
- Delegate mail. Record the delegate and the scopes they act with.
What it doesn't do (yet)
There is no detection of unused or dormant accounts; an old updated date is a date, not an alert, and deciding what is dormant is still yours. Password reset can be configured to require a step-up check that is not implemented yet; such tenants get an explicit error rather than a silent pass. There is no identity-provider integration. OAuth grants held by these accounts live in their own inventory, not in this register.
What access it needs
Reading the register uses the Directory user scopes granted at connection. Suspend and password reset write through the Admin SDK. See the scopes page.
Questions admins ask
- Where does the reset password go?
- Nowhere but your screen. It is returned once and never persisted.
- Can I find accounts nobody has touched in a year?
- Not automatically. The register shows the updated date; dormancy detection does not exist.
- Who can reset a password?
- Admins holding the tenant's service-account admin role.
Related modules
Teams (ownership), Requests (ownership and alias requests), DataScout (OAuth apps connected to the Workspace). The Teams, Requests and DataScout pages are not up yet.