Managing your team

What an admin can do

As an organisation admin you look after the people on your team from the Team page. You decide who is on the team, what they can do, and whether their access is switched on.

There are three roles. Most people are trainees, who work through the range. A manager runs training for the organisation: they schedule and facilitate exercises, read what training has happened, and mark written work. They author no labs, invite nobody and change nobody's role. Admins can do everything a trainee can, and they also manage the team. Everything on this page assumes you are signed in as an admin; where a manager can do something too, it says so.

A manager is scoped to the whole organisation rather than to a subset of it, because the platform has no unit smaller than an organisation for a role to be confined to.

Signed in as a manager you reach the same admin area an admin does and see less of it: the sections your role opens, and no others. A page you cannot use is not shown rather than shown and then refused, and the interface works that out from the same permission list the API enforces, so the two cannot disagree.

Your control covers your own team only. You will never see or change people who belong to a different organisation.

Inviting a teammate by email

You can invite someone before they have ever signed in. On the Team page, enter their email address and choose the role you want them to have. This creates a pending invitation.

Inviting does not create an account. No account exists until the person signs in for the first time and their email address is confirmed. How they are prompted to sign in depends on how your range is set up, so you may need to let them know to sign in.

When they do sign in, and the confirmed email on their sign-in matches your invitation, they join your team with the role you chose, even if their sign-in would otherwise have placed them elsewhere. Because the match is made only against a confirmed email address, nobody can join your team by claiming an address that is not theirs.

• A pending invitation can be revoked at any time before the person signs in. Once revoked, it will not let anyone join.
• Invitations expire after a while. If one lapses, you can simply invite the same address again.
• You cannot have two pending invitations open for the same email address at once.

Signing in with your own identity provider

Your organisation can sign its people in through its own identity provider, over SAML 2.0 or OpenID Connect. Open Admin, then Single sign-on, pick your provider from the list, and tell us the name your staff will recognise and the address of your provider.

Picking Entra ID, Okta or Google Workspace fills in the shape of the address and says where to find it in that admin console. You still replace the placeholder with your own value: the id in it is yours and we cannot know it, and a template that looked finished would be pasted unchanged and fail at the first sign-in.

Claim your domains on the same page. Each one gets a DNS TXT record to publish, and we check for exactly that value at exactly that domain. Claiming a domain proves nothing on its own and nothing here pretends otherwise; publishing the record is the proof.

You can retire password sign-in once your people are actually arriving through your provider. It stays available to the admins who hold the way back in, because an outage at your provider would otherwise lock your organisation out of its own account, including out of turning single sign-on off.

That records a request. It does not switch single sign-on on. Creating an identity provider is creating a way into the platform, so our application deliberately holds no permission to do it and one of our operators applies your request by hand. Expect that to take a short while rather than to be instant.

Check it before you ask us to apply it. The Check button fetches the document at the address you gave and tells you what is wrong with it: an address we cannot reach from the internet, the wrong kind of document, or one that names a different issuer to the address it sits at. That last one is the common mistake, and left alone it fails much later when a token is validated, with an error that looks nothing like its cause.

A passed check means your details are consistent with each other. It is not a promise that sign-in works, because it cannot see what we have set up on our side, and we would rather tell you that than show you a tick you would reasonably misread.

Once it is applied, the page reports whether it works, and it does that by watching your people actually sign in rather than by inspecting the configuration. Until somebody has signed in through it, the page says nobody has, and it will not guess between not-yet-applied and applied-but-wrong, because from where it sits those look the same. Signing in once settles it.

• The address must be https. It is where your people's sign-in is handed to, so a plaintext one would send them somewhere that could be intercepted.
• Keep at least one admin who signs in with a password. Once your people are arriving through your provider, we refuse to demote or deactivate the last one, because an outage at your provider would otherwise lock your organisation out of its own account.
• An admin who never actually uses their password is not really a way back in. Sign in that way from time to time.
• Withdrawing the request removes it from your organisation. An operator still has to take the provider itself down.

Granting or revoking the admin role

To change what a teammate may do, open them on the Team page and pick their role. You can move somebody between trainee, manager and admin as often as you need, and an invitation carries a role too, so somebody can arrive as a manager rather than being promoted afterwards.

A role change takes effect the next time that person uses the range. Their progress and place on the team stay exactly as they were; only what they are allowed to manage changes.

Switching access on or off

When someone leaves the team, or should be paused for any reason, you can deactivate their access instead of removing them. Deactivating blocks them from the range while keeping their record, so nothing is lost.

This takes effect the next time they try to use the range. Note that deactivating stops them inside the range but does not force-close a session they already have open elsewhere at that moment; it applies on their next visit.

When they should return, reactivate them and their access comes straight back, with the same role they had before.

The one-admin safeguard

A team always keeps at least one active admin, so it can never lock itself out. Because of this, you cannot remove your own admin role and you cannot deactivate yourself. Those actions are refused.

If you need your own role changed or your own access switched off, ask another admin on your team to do it for you. If you are the only admin, promote a colleague first, and then they can make the change.

This safeguard holds even if two admins act at the same moment, so there is always someone left who can manage the team (see ADR-042).