What is the right order for setting up a new Google Workspace user?

Licence first, because an automatically assigned licence can take up to 24 hours to apply. Then create the account with its organizational unit set on the creation form, a secondary address for the credentials and a forced password change. Then groups, then shared drives at a chosen access level, then the Two-Step Verification enrollment window, then devices. Finish by watching the person sign in, enrol and send one external message.

Why can a new user not sign in after we turned on 2-Step Verification?

Setting up a second factor requires being signed in, so a brand new account created under full enforcement can be locked out before it is ever used. Google provides a new user enrollment period, from one day to six months, during which the person can sign in with a password alone. Use it, enrol them on the first day with somebody present, and do not leave the enrolment to chance.

Should a new hire get Content manager access to a shared drive?

Content manager is the default for new members and it can delete files, so grant it only where the person really works in that drive. Contributor adds and edits without deleting, which fits most new hires, though note that in Drive for desktop Contributor gives read access to files only. Commenter and Viewer suit drives that hold finished material.

Google Workspace onboarding checklist: every step, in order

Say a nine-person insurance brokerage hires an account manager who starts on a Monday. The account was created late on Friday. She signs in, Gmail works, Drive is empty. The policy templates she needs sit in one of three shared drives and nobody remembers which. The address clients have written to for two years still belongs to the person she replaced. By Wednesday somebody has fixed it all by hand, including two drives she should not see, and nothing is written down.

Onboarding fails in two directions. Either the new person can see nothing and the first week goes on asking, or somebody fixes that by granting access file by file and the account can no longer be unwound when they leave. Both come from the same steps in the wrong order. This is the order we use on client projects, and the settings that generate the calls.

What we settle before the account exists

Five answers, none of which need the Admin console open.

Which organizational unit they belong to. A user sits in exactly one and inherits its settings, so this choice has the longest reach of anything you do today.
Which groups they join. Groups are what you remove in eighteen months. A file shared with them personally is what you forget.
Which shared drives, and at what level. Two questions, and most people answer only the first.
Whether they inherit an address somebody else answered, and whether they will send from it.
Whether they get a managed phone. Basic mobile management is on by default and installs nothing, but screening a device before it reaches company mail means advanced management, a device policy app and a licence that supports it, so check before you promise it.

Google's structure guidance is worth repeating at this size: below roughly fifty users, organizational units on their own usually carry everything.

Create the account, in this order

The licence first. Automatic licensing is set per subscription under billing and license settings, child units inherit and can override the parent setting, and an automatically assigned licence can take up to 24 hours to take effect. That last clause is what ruins a Monday start, so when an account has to work the same morning we assign the licence by hand. Two notes from the same page: it can only be on for one subscription, and a user added by CSV into a unit that has it on gets the automatic licence, not the one the CSV specified.

The account, with the organizational unit set at creation. Under Directory and then Users, Add new user takes the name and the primary address, and the panel underneath holds the organizational unit, the password and the photo. Set the unit here. A user created without touching it lands in the top-level unit, usually the one with the loosest settings, and moving them later means the policies they first signed in under were not yours.

A secondary address. The same form takes a secondary email so the person receives their account details, which for a new hire is their personal address and beats reading a password out on a call.

A password they are forced to change. Password rules live under Security, Authentication and Password management, apply per organizational unit, and allow 8 to 100 characters with a minimum of 8 by default. The trap is in Google's own fine print: strength and length requirements do not apply to a password an administrator resets by hand. So the box asking the user to change their password at next sign-in is the only thing applying your policy to the password you just typed. The rules also stand aside for sign-ins through an external identity provider over SAML or OIDC.

Two-Step Verification, and the window that locks people out

This is where new accounts actually break. Under Security, Authentication and 2-step verification, a super administrator sets enforcement and, separately, a new user enrollment period that can run from one day to six months. Inside that window the new person signs in with a password alone. When it closes, enforcement applies to them like everybody else.

Google documents both ways this goes wrong: a user who never enrols before the window closes, and a newly created user who cannot sign in at all, because setting up a second factor requires being signed in. Enforce with no enrollment period and you get the second one on the first morning. The workaround Google describes is a group where enforcement does not apply until people enrol, and Google adds that it is not recommended as standard practice. The honest version: use the enrollment period, and make enrolment part of the first thirty minutes with somebody watching.

Two details worth knowing. Enforcement set with the from-a-date option begins within 24 to 48 hours of the date you picked, so when you need it live at a known moment use the plain on setting. And enrolment reporting can lag by up to 48 hours, so when you are chasing one person, read that user's security settings instead.

Groups before individual sharing

This habit decides whether an eventual departure takes a morning or a week. Put the person in groups, grant the groups access, and never grant a person access to a file directly when a group would do.

Units and groups are not interchangeable. The organizational unit carries the baseline, one per user, inherited down the tree. A configuration group makes an exception without redrawing that tree: a user can belong to several, a group setting beats the unit setting, and where somebody is in two, your priority order decides. One catch that costs an afternoon: the group has to be a security group to be used this way, and a group created in Google Groups will not appear in the picker until it is.

For a team of ten, three or four groups covers it, named for what they grant rather than for the department that holds them today.

Shared drives: pick the level, not just the drive

Adding somebody to a shared drive is two decisions, and the second gets skipped. The five levels, from the top: Manager, Content manager, Contributor, Commenter and Viewer. New members default to Content manager, which can upload, edit, move and delete everything in it.

Manager is the only level that can change other members' access, delete the drive, or empty files out of the trash for good. A new hire does not need it on day one.
Content manager is the working default, and it includes deleting. Google's advice is plain: if you are worried about members deleting files, Contributor, Commenter and Viewer are the levels that cannot.
Contributor adds and edits but does not delete. Worth knowing before somebody reports a bug: in Drive for desktop, Contributor gives read access only, which surprises anyone working out of the synced folder rather than the browser.
Commenter and Viewer suit a drive that holds finished work, which is how Google frames the choice too.

Two neighbouring settings are cheaper now than retrofitted after a drive has been shared with a client: a Manager or an administrator can stop Content managers sharing folders outward, and stop Commenters and Viewers downloading, copying or printing.

The address questions that land on day one

A new hire inheriting somebody else's address is the common one, and the answer turns on whether one person or several will answer it. An alias is for one person: up to 30 per user at no extra cost, added from the user's own page under alternate emails, and only one account receives mail sent to it. Where several people need the same address, Google's recommendation is Gmail delegation, and we compared the four ways to run a shared address separately.

Three things about aliases generate tickets. An alias is not a Google Account, so nobody signs in with it. It cannot reuse the name of an account that already exists in your organization, which is why a departed colleague's address often has to be freed first. And sending from an alias is configured by the user in Gmail, not by you in the Admin console, so you can hand one over and still have somebody unable to send as it.

One dated item, if the new hire wants to keep working out of an old personal address. Google's Gmail help page states, checked 9 October 2026, that from January 2027 Gmail will no longer support send-as for third-party addresses such as @outlook.com, and that Workspace aliases are not affected.

Prove it before you hand over the account

Three checks, with the person in front of you:

They sign in, change the password, and enrol in Two-Step Verification. Now, not after the enrollment window closes.
They open each shared drive they are meant to have and try what the job needs: edit a document, move a file, create a folder. A Contributor who needed Content manager finds out here instead of during a deadline.
They send one real message to an outside address, from the address they will actually use, and you read the headers on the receiving side. If they inherited an address, or you configured a send-as, this is where you learn whether it authenticates as your domain. We wrote up the relay and send-as side separately.

What you want on that test message, with your own domain in place of the example:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@example.com
       designates ... as permitted sender);
       dkim=pass header.i=@example.com;
       dmarc=pass (p=REJECT sp=REJECT) header.from=example.com

Three passes, and a header.from on your own domain. Anything else is work to close before the new person mails a client.

What we watch for the first week

Whether enrolment in Two-Step Verification happened, read from that user's security settings rather than a report.
Any file shared with the person directly instead of through a group. Each one is a line item in a future departure.
Access granted that turned out not to be needed. Week two is the cheapest moment to take it back.
Bounces or spam placement on a newly inherited sending address, which carries somebody else's history.

How Guanacos Tech helps

We do this as part of Workspace work for small and mid-sized teams across North America and Latin America. The unit and group structure gets designed once, so every later hire is a short job rather than an afternoon of judgement calls, then the account, the drives at the right level, the enrollment window, and the test message that proves the mail side. The departure half is the same checklist backwards, and how we work fits on one page. If you would rather have this set up than researched, we are Google Workspace consultants, and half an hour settles the structure for your team.

The Google Workspace onboarding checklist: what to set up before a new hire signs in