Client Onboarding
Onboarding brings a client workspace into your roster through a delegation grant. New workspaces start at full operational so you can begin setting them up immediately. Existing workspaces require client approval first. Choose the route based on whether the client already uses Glow and who should own signup.
This page assumes the client layer is already on your workspace, which is what gives you the console referenced below. Your account team switches it on with you: see Getting Set Up.
Open your console and select Client. The New client dialog opens.
Choosing a mode
| Mode | Use when | Client appears in your roster | Starting tier |
|---|---|---|---|
| Create workspace | New client, you set everything up for them | Immediately | Full operational |
| Invite by email | New client, they should own the signup | When they accept | Full operational |
| Add existing team | They already use Glow | When they approve | Whatever the client consents |
The first two modes create a new workspace with an active full-operational grant. Create workspace also makes you an Admin so you can configure the workspace immediately. With Invite by email, the grant becomes active when the client accepts. Only Add existing team asks the client to approve a tier before access begins.
Which mode to choose
- MSP / Ongoing Operations: Use Create workspace to set up and manage client automations directly.
- Consultant / Project Handover: Use Invite by email so the client owns their workspace from day one, making handoff clean and immediate.
- Existing Glow Users: Use Add existing team to request scoped delegation access to an existing organization.
Create workspace
You create the client’s workspace yourself and start building right away. Fastest route, and the one to use when the client would rather you handled setup.
Pick the mode
In New client, choose Create workspace and give it a name, such as Acme Corp — Managed.
It is yours to configure
The workspace appears in your roster immediately with an active full-operational grant. You are also added as an Admin, so you can switch into it and start building without waiting for anyone.
Hand it over
When the build is ready, invite the client’s people and make their lead an Admin. Invites and roles work as described in Team Management. With an Admin of their own in place, the workspace is genuinely theirs to run.
Set up a clear handover. Add a client Admin before handover, then review both your team membership and the delegation grant with them. Team Management covers workspace roles, while Governance & Impersonation covers delegated access.
Invite by email
The client creates their own workspace from a link you send. Use it when they want ownership of the signup, or when their IT prefers accounts created by their own people.
Send the invite
Choose Invite by email and enter the client’s address. They receive a co-branded invite.
They sign up
The link takes them through signup, and the workspace is created when they accept. It is born under your governance, at full operational: an invite carries fixed terms rather than a tier you pick when sending it.
They appear in your roster
Until they accept, the invite sits in Pending. Nothing exists on your side yet.
This one starts at full operational too. The client owns the signup, but the tier comes from the invite rather than from a choice they made. Same responsibility as above: tell them where it starts, and point them at Settings → Governance, where they can narrow it or end it.
Add existing team
The client already uses Glow. Nothing is created. You ask for access to what they have.
Get their workspace ID
Ask the client’s admin to read it off Settings → General and send it to you.
There is deliberately no lookup by name or email. Without that restriction, anyone could probe whether a given company uses Glow.
The ID on its own is not a key to anything. Requesting access needs an Admin account in a workspace Glow has enabled as a practice, and the client’s own Admin still has to accept. A client can therefore share the ID over ordinary channels without it becoming a way in.
Send the request
Choose Add existing team, paste the ID, and pick the access tier you need. See Access Tiers. Take the narrower one unless you genuinely need to act on their behalf.
They decide
Their admins see exactly what you asked for: tier, scope, and expiry. Nothing changes until one of them accepts, and they can downgrade the tier or limit it to specific workflows first.
Unlike the other two modes, this one cannot put the client in your roster on submit. The grant stays Pending until a client admin approves it.
Pending invites and requests
The Governance tab of the console lists everything outstanding: invites not yet accepted, requests not yet approved.
If an invite expires or is caught by a spam filter, Resend or Cancel it from that table rather than sending a second one.
What’s Next?
👉 Governance & Impersonation → — understand what each access tier permits before working inside a client workspace.
Sideways from here: Team Management covers the roles you assign inside a workspace.