People and groups

One person, one sign-in

Everyone who uses Inline has their own account, identified by the email address they sign in with. That is what makes the rest of the product legible: a call in Activity names a person, a held call in Approvals names who may decide it, and a key belongs to somebody. A shared credential answers none of those questions.

People are added on the People page, which is an admin page. You give an address, a role, optionally an end date, and optionally the groups they should be in.

Roles

A role decides what someone can do in Inline itself — not what a tool can do, which is the job of servers, keys and rules.

Role	What it lets them do
Owner	Everything an admin can do, and decides who the admins and owners are.
Admin	Manages people, sources, rules, every server and the logs.
Builder	Composes servers, shares them and issues keys for them.
Member	Uses servers shared with them and connects their own accounts.
Auditor	Reads the activity and admin logs. Cannot change anything.

Only an owner can give someone the owner or admin role; for anybody else those options are shown but not selectable. A few settings are an owner’s alone, including sign-in with your company’s identity provider and the workspace-wide approval policy, because each one changes what is true for every server at once.

Groups

A group is a way to share a server with a team rather than listing people one by one. Whoever is in the group when they connect can use what the group has been given. A group has a name and a short name; renaming it keeps every share, because servers refer to the short name.

Members can be listed in Inline, or a group can be synced from a Google Workspace group — in which case its membership comes from there, and the page shows when it last synced. Syncing on demand is only available where Google Workspace sync is turned on for the deployment.

Sign-in with your company’s identity provider

An organisation can register its own SAML or OIDC providers. Create the provider in Identity Platform first; Inline keeps its id, its name and the domains that must use it, never a certificate or a client secret.

Claiming a domain is a strong act. Anyone whose address is at a claimed domain can then only sign in through that provider — Google sign-in and one-time email links are refused for them, on the server. Removing the provider gives those people the ordinary ways back straight away, which is what you do if the provider itself stops working. Until somebody has signed in through a provider, the page marks it as not yet used, because a wrong id looks fine until it is tried.

Two-step verification

Two-step verification uses an authenticator app showing a six-digit code. Any person can turn it on for themselves from their own page. Requiring it of chosen roles and groups is a setting of the whole deployment, so today it is set up with us and not by a workspace owner. Somebody who is required to have it and has not set it up can reach the set-up page and nothing else until they do.

It depends on TOTP being enabled in Identity Platform; where that has not been done, Inline says so rather than failing quietly. A lost authenticator cannot be recovered — the code only ever existed in the app on the device — so an owner clears the enrolment on the People page and the person sets up a new one. That act is recorded with who did it, and it removes a second factor from an account, so check who is asking.

When someone leaves

Removing a person stops them signing in, and every session, connector and key they hold stops working immediately. Servers they composed stay and can be deleted separately. Their history in Activity is untouched.

An end date is the gentler version: access closes at the end of that day. Admins can also revoke ended access on demand, which signs out everyone whose end date has passed, from every session and key, at once. That cannot be undone.

Inline is early, and what it does and does not claim about security is set out on the security page.