# Client Onboarding

> Three ways to bring a client under management: create their workspace, invite them to create it, or request access to one they already have.

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](/msp/overview#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](/manage/workspace-settings/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](/manage/workspace-settings/team-management) covers workspace
> roles, while [Governance & Impersonation](/msp/governance) 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](/msp/governance#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 →](/msp/governance)** — understand what each access tier permits before working inside a client workspace.

Sideways from here: [Team Management](/manage/workspace-settings/team-management) covers the roles you assign inside a workspace.