How to automate Google Workspace account creation safely

Creating a Google Workspace account takes a minute by hand, which is why it is usually still done by hand. The case for automating it is not the minute — it is that manual provisioning produces inconsistency, and inconsistency in access is a security problem rather than an inconvenience.

The other half of the case is offboarding, which is the part almost nobody automates and the part where the consequences are real. An account created by hand and never removed is the most common finding in any access review.

What we'll cover

• Why consistency matters more than time
• Access belongs to groups, not people
• What to derive and what to ask
• Building it with CodeWords
• Offboarding, the half that is skipped
• Licences, which cost money quietly
• The credentials problem
• Beyond the account itself
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why consistency matters more than time

Manual provisioning drifts. Two people in the same role end up with different group memberships because two different administrators set them up.

Nobody can answer what a role should have, because the answer exists as an accumulation of decisions rather than as a definition.

Copying an existing user is the usual shortcut and it propagates whatever that person accumulated, including access they should not have had either.

Auditing becomes impossible. "Does everybody in this role have the right access" cannot be answered when there is no definition of right.

Automation forces the definition. You cannot automate provisioning without writing down what each role gets, and that document is worth more than the time saved.

Access belongs to groups, not people

The single most important design decision here.

Grant access to groups, and put people in groups. Never grant directly to an individual.

Because removal is then one action. Taking somebody out of a group removes everything that group conferred; unpicking individual grants is archaeology.

Group membership is auditable in a way scattered individual permissions are not.

Name groups by role or function, not by tool, so the membership question is "what does this person do" rather than "which systems did somebody add them to".

Shared drives, calendars, and third-party tools should all grant to the same groups, which makes the group the single point of control.

Review group membership periodically, which is a short task when access is grouped and an impossible one when it is not.

What to derive and what to ask

Derive from the HR system wherever possible — name, role, department, manager, start date — since that is the record that exists and the one that gets updated.

Do not ask a form for what the HR system knows, because the two will disagree and nobody will know which is right.

Ask only for what is genuinely discretionary, such as an unusual access need with a reason attached.

Trigger on the HR system, not on a request, so provisioning happens because somebody was hired rather than because somebody remembered to ask.

Handle the start date. An account created three weeks early is three weeks of an unused account with access, which is worth avoiding.

Report what could not be derived rather than guessing at a department or a manager.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so provisioning can be driven from the HR system and extend to the other tools a role needs.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what triggers provisioning, what each role gets, and who is told.
3. Authorize the connection with a service account holding the narrowest admin scope that covers what you provision.
4. Describe the exceptions: a role that is not in your mapping, a duplicate account, a start date in the past.
5. Test against a non-production domain, or a test user, before anything touches real accounts.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Offboarding, the half that is skipped

Automating creation without automating removal makes the security position worse rather than better, because accounts now appear faster than they disappear.

Suspend immediately on the leaving date, which stops access without destroying anything.

Do not delete straight away. Data, ownership of files, and calendar entries all need handling first, and deletion is irreversible.

Transfer document ownership to the manager or a successor, which is the step that causes the most disruption when it is skipped — files owned by a deleted account become inaccessible.

Remove from groups, which is one action if you followed the rule above and a long list if you did not.

Handle the shared credentials that person knew, which is a separate task nothing automates and which a leaver checklist should include.

Report anything that could not be transferred, so it is dealt with rather than left.

Run a reconciliation between the HR system and the directory monthly — anybody present in one and not the other is exactly the finding you want.

Licences, which cost money quietly

Licences are usually assigned per account and continue for suspended ones unless removed.

A suspended account with a licence is a recurring charge for somebody who left, and it persists until somebody audits.

Release the licence on suspension, deliberately, as part of the offboarding automation.

Report unassigned licences monthly, since over-purchasing is common and nobody checks.

Watch the account created early for a start date that moved, which is a licence consumed for nothing.

This is the part of the automation that pays for itself in a way that is easy to demonstrate, which is useful when asking for time to build it.

The credentials problem

An automation that creates accounts sets initial passwords, which is a credential that has to reach a person who does not yet have an account.

Do not email it to a personal address as a matter of routine, and certainly not without a forced change.

Use your identity provider's flow where you have one, which avoids the problem entirely by never creating a password.

Force a change on first sign-in and require multi-factor enrolment before granting meaningful access.

Never log the credential, which is easier to do accidentally than it sounds.

The admin credentials the automation itself holds are the more important ones: scope them narrowly, store them in a secret store, rotate them, and alert on their use outside the expected schedule.

Beyond the account itself

An account is one of several things a person needs on their first day, and the others are usually where the delay is.

Map role to tools, once, and provision the whole set rather than the mail account alone — because the second day spent requesting access is the part people remember.

Not every tool should be automatic. Anything with a per-seat cost or elevated privilege deserves a request with an approval rather than a default grant.

Handle the tool with no API by creating a task for whoever administers it, so it is tracked rather than forgotten.

Sequence it. Some tools need the mail account to exist first, which means a first-day provisioning run is a small workflow rather than a set of independent calls.

Tell the manager what was provisioned, so they can spot a gap before the person does.

Apply the same mapping at offboarding, in reverse, which is the only way the removal side stays as complete as the creation side.

Making it survive

Make it idempotent, keyed on the person, so a retried run does not create a second account or reset an existing one.

Handle the name collision, which is common and needs a defined rule rather than a failure.

Report rather than guess when a role is not in your mapping.

Never delete automatically. Suspension is reversible and deletion is not, and the automation should stop at the reversible step.

Report the outcome. Accounts created, suspended, licences released, and anything that needed a person.

Limits worth knowing about

Admin API access requires elevated privileges, and the account holding them is a high-value target that deserves the strongest protection you have.

Directory changes take time to propagate across services, so an account may not have everything immediately.

Some settings are domain-wide rather than per user, which constrains what per-person automation can do.

Rate limits apply, which matters for a bulk onboarding.

Employment records are personal data with its own obligations, and an automation moving it between systems is processing it — worth confirming the basis before rather than after.

What to build first

Offboarding, not onboarding. Suspend on the leaving date, remove group memberships, release the licence, and transfer document ownership, driven from the HR system. It is the half that carries actual risk, it is almost never automated, and the licence savings alone usually justify the work.

Two habits make the difference. Grant access exclusively through groups, since that single rule turns offboarding from archaeology into one action. And reconcile the directory against the HR system monthly, because anybody present in one and not the other is the finding every access review is looking for.

Frequently asked questions

Is automating account creation worth it for a small team?

The creation, marginally. The consistency and the offboarding, yes — manual provisioning drifts, and accounts created by hand and never removed are the most common finding in any access review.

Why grant access through groups?

Because removal becomes one action. Individual grants have to be unpicked one by one, which means they are not, which means leavers keep access nobody can easily enumerate.

What should trigger provisioning?

The HR system, not a request form. Provisioning should happen because somebody was hired rather than because somebody remembered to ask, and the HR record is the one that gets kept up to date.

Should the automation delete accounts?

No. Suspend, which is reversible and stops access immediately. Deletion destroys file ownership and is irreversible, so it belongs behind a person's decision after transfers are complete.

What is usually missed at offboarding?

Document ownership transfer and the licence. Files owned by a deleted account become inaccessible, and a suspended account keeps costing money until somebody audits — often months later.

How should initial passwords be handled?

Ideally not at all — use your identity provider's flow so no password is created. Otherwise force a change on first sign-in, require multi-factor enrolment, never log it, and do not routinely email it to a personal address.

How do I find accounts that should not exist?

Reconcile the directory against the HR system monthly and report anybody in one and not the other. It is a short automation and it surfaces exactly what an access review is looking for, continuously rather than annually.

Should the automation provision every tool?

Map role to tools and provision the routine ones; leave anything with a per-seat cost or elevated privilege behind a request and an approval. For tools with no API, create a task so it is tracked rather than forgotten.

How do I keep offboarding as complete as onboarding?

Use the same role-to-tool mapping in reverse. The removal side drifts out of step whenever it is maintained separately, which is how leavers keep access to the tools nobody listed.

Related reading

• Automated customer onboarding
• API authentication methods
• OneDrive and CodeWords