Clients

Clients (/clients) lists every client workspace the account runs, with its protection, licence, seats and your own access to it in one row. It needs msp.clients.view. If your account limits you to some clients, you see only those. Creating and changing clients needs msp.clients.manage; opening one needs msp.clients.access.

​

Creating a client workspace

New client collects:

• Name for the workspace.
• First admin, invited by email. They receive an invitation to set a password, exactly as any invited admin would, and become the client’s own admin, not a member of your account.
• Seats, taken from the account’s own seat pool. The dialog shows how many are free and will not let you request more than that.
• Licence, either the same as your account (it follows your account live: a module you gain or lose, or a renewal, carries straight through) or its own end date and its own set of modules and limits, bounded by what your account holds.

The workspace is created and its first admin invited in one step. If the invitation email cannot be sent, the dialog stays open with a one-time link you can hand the admin yourself. Creating clients is limited to 20 an hour and 60 a day per account, shared by every admin in it. Attempts that are refused for missing permission or for invalid input do not count against it.

​

What a client is sold

A client’s licence is your own licence, folded in: anything you do not state for it, it inherits live from your account.

• Modules: a client can hold any module your account holds, and no other. A module your account loses is withdrawn from every client that had it on the next read, rather than living on in a stale copy.
• Plan tier: a client’s tier can be anything at or below your account’s own (Free or Enterprise; Trial is a state a licence falls into, not one you assign).
• Pools: seats, Runtime Security calls, and endpoint devices are sold to your account as a shared budget. While a pool is sold, every client that draws on it must carry a stated share. Leaving it unstated would give that client no cap at all. A pool your account was never sold is not yours to split; clients simply follow your account’s own figure for it.
• Ceilings: everything else numeric (scans, concurrent scans, queue size, datasets, storage, max dataset size) can be set for one client up to your account’s own figure, and is inherited when you leave it alone.
• Term: a client’s licence can end before your account’s own and never after it. Left unset, it renews with your account.

​

Changing seats and licence

Choose Change on a client’s row. Seats and licence are saved in one request. Seats cannot be set below the client’s own active people and pending invitations, or above what the rest of your clients leave free in the pool. The change replaces your whole stated decision for that client; leaving a licence field out puts it back on following the account. A seats value you leave out is kept as it is. Follow the account drops your decision entirely. It is refused if the client would be left with no stated share of a pool your account sells: an unallocated pool is exactly the situation the pooled-limits rule above exists to prevent.

​

Clients waiting for seats

A client that was approved for your seat pool but holds no seats yet shows Waiting for seats in the Licence column. It is waiting for you, not for Blindsight. Overview lists it under Needs attention as Give it seats, and its action opens that client’s Change dialog.

​

Clients that keep their own licence

A client that chose, when it approved being linked, to keep its own licence pays Blindsight directly. Its row shows Own licence where Change would be, because its seats and licence are its own and msp.clients.manage cannot touch them. It is never billed by the account and takes no seats from the pool. It is still listed in Billing with Kept as its licence, so you can see it. See Linking a workspace.

​

Tags

Tags are short labels you put on your own clients, such as dental or emea. They filter the Clients table, and they decide which clients a scoped operator can see (see Limiting an operator to some clients). Choose Tags on a client’s row to edit them; it needs msp.clients.manage. A tag is letters, numbers, spaces, underscores or hyphens, up to 40 characters, starting with a letter or number. Tags are saved in lowercase, so Dental is accepted and kept as dental. A client carries at most 10 tags and the account uses at most 100 distinct tags. Tag changes are recorded with who made them. A client that is released loses its tags, so linking it again starts it untagged.

​

Releasing a client

Release on a client’s row ends the link from your side. It needs msp.clients.manage, and two-factor authentication turned on for your own account. You prove it with a current code from your authenticator app and by typing the client’s name. There is no password option. Releasing a client:

• Ends every session open into it, at once.
• Returns the seats it held to your pool, unless it kept its own licence, in which case its licence is unaffected.
• Flags a pool client’s licence for Blindsight to resolve with the client.
• Deletes nothing. The client keeps its workspace, people, devices, policies and audit trail, and your past sessions stay in Activity.
• Emails the client’s admins to tell them.

You can later send the workspace a new link request. A client can also end the link itself: see For clients.

​

The Clients table

​

Next