People account recovery

Step-by-step recipes for the things that go wrong with people’s accounts, and for the periodic access review. Everything here is done by a System Admin in the Console, under Admin, People and access. For what each page does, see the guide People and roles.

Section	When
A. Email not confirmed	“Your email is not confirmed yet. Ask an administrator.”
B. Lost authenticator	A person cannot give the code.
C. Change an email address	A person has a new address.
D. Remove a person for good	Deactivate or delete.
E. A person left the company	Offboarding checklist.
F. Periodic access review	Every quarter.
G. Why can’t this person do X?	A person is refused something.

Before you start (all sections)

• You are a System Admin. The authenticator rule applies to you: if a page says “Verify your authenticator first”, choose Verify now, enter the code and repeat the action. (If a System Admin turned the authenticator rule off on Admin, System, Security, nobody is asked for a code.)
• Confirm who is asking before you change an account (A, B, C and E especially). For B, confirm out of band (phone or in person), never only by email or chat.
• Every action on this page is written to Admin, System, Audit log. Nothing here prints a secret, except the password you set yourself.

A. Someone cannot sign in: “Your email is not confirmed yet”

The person was invited by email and never accepted the invite, so the sign-in service refuses their password. The Console shows “Your email is not confirmed yet. Ask an administrator.” on the sign-in page; the Station shows the same message because its sign-in happens on that page.

Prerequisites: a System Admin session verified with the authenticator. The person’s email address.

Steps

1. Open Admin, People and access, Users. Search the person by name or email and select the row.
2. Look at the state chip in the sheet header. Invited means the invite was never accepted. The Account tab says “Invite not accepted”. (If Orbit could not read the sign-in status the chip says Active; the actions below still work.)
3. Pick one:
   • Resend invite (Account tab): the person gets the link again and chooses their own password. Message “Invite sent again to ”. Use this when the address is right and they can read it.
   • Confirm email (Account tab): choose Confirm email and confirm in the dialog (“Confirm without them opening the invite? They can sign in with the password you set.”). Then they can sign in with a password. Use this when they cannot get the mail. If they have no password yet, set one in step 4.
   • Set a new password… (Security tab): choose Generate (16 characters) or type one of at least 12, then Save password. This also confirms the email.
4. If you set a password, give it to the person yourself, in person or by phone. Orbit shows it once in the Security tab (“Password changed. Give it to yourself”). Tell them to change it in Profile, Security.
5. Ask the person to sign in again. The state chip changes from Invited to Active after the Users page reloads.

What can go wrong

• No Confirm email button. It shows only for an Invited account that is not deactivated. For a deactivated account, reactivate first.
• The person still cannot sign in. Check the State: Deactivated or Expired accounts are refused for another reason (reactivate, or set a new expiry in the Account tab). Check the address on the row is the one they type (section C if it is wrong).
• “Verify your authenticator first”. Choose Verify now, enter the code, repeat.
• Set a new password does not end other sessions. If you suspect someone else holds the account, see section E.

Values to record

None of these are secrets, except the password.

Key	Where found	Keep
Who asked, when, how you confirmed them	Your own ticket or log	Not secret
The action taken (Resend invite, Confirm email, Set a new password)	Admin, System, Audit log (user.invite_resend, user.confirm_email, user.password_set)	Not secret
The password you set	Shown once in the Security tab	Secret, shown once. Hand it over and do not write it down. The person changes it at once.

B. Someone lost their authenticator

The person cannot give the 6-digit code, so admin pages (for a System Admin) or the Station sign-in (while the switch is on) stop at the code step. Orbit has no recovery codes: the fix removes their authenticator so they enrol a new one.

This section is for resetting another person’s authenticator. If you are the one who lost yours, you cannot reset it yourself: another System Admin does it for you with these steps, and if you are the only System Admin, the person who runs your Orbit installation removes it for you in the sign-in service. Make sure you always have at least two System Admins.

Prerequisites: a System Admin session verified with the authenticator. The person is not you. You have confirmed the request out of band.

Steps

1. Open Admin, People and access, Users and select the person.
2. Open the Security tab. Choose Reset authenticator.
3. Read the dialog: “Remove every authenticator of ? They set up a new one at their next sign-in while the authenticator rule for System Admins is on. Their other sessions stay open.” Choose Reset authenticator.
4. A message says “Authenticator removed (N)”. If it says “There was no authenticator to remove.” the person had none, and nothing was changed.
5. Ask the person to sign in. While the switch is on, a System Admin is sent to Set up your authenticator (scan the QR code with an app such as Microsoft Authenticator or 1Password, then enter the code). Other people can add one in Profile, Security, Set up authenticator.
6. After they enrol, open Admin, System, Audit log and check what the account did since the authenticator was lost.

What can go wrong

• No Security actions on the row. You are on your own row. Another System Admin must do it.
• “Verify your authenticator first”. Choose Verify now and repeat.
• The reset stopped half way (an error after some factors were removed). The ones already removed stay removed and the audit log records the count. Choose Reset authenticator again.
• The person’s other sessions stay open. A reset does not sign anyone out. If the device is lost, they use Sign out other devices in Profile, Security once back in.
• The switch is off. Nobody is asked for a code; the reset still removes the factors, and people who enrolled an authenticator keep it until it is reset.

Values to record

None are secrets.

Key	Where found	Keep
Who asked, when, how you confirmed them	Your own log	Not secret
The reset itself	Admin, System, Audit log (user.reset_authenticator, with the number removed)	Not secret
The new authenticator’s secret key	Shown on the person’s own screen while they enrol	Secret, shown once, theirs alone. Never ask for it.

C. Change someone’s email address

Use this when a person’s address changed (a rename, a new company address). The address is also the one they sign in with.

Prerequisites: a System Admin session verified with the authenticator. The new address, and a way to confirm the request with the person (they ask from the old address or you call them). The person is not you (use Profile for your own).

Steps

1. Open Admin, People and access, Users and select the person.
2. On the Security tab choose Change email…. A form opens.
3. Type the New email address. It must be a valid address and different from the current one (the form shows “Now ”).
4. Decide the checkbox Mark the new address as confirmed:
   • On (the default): you vouch for the address, and the person can sign in with it at once.
   • Off: the sign-in service sends a confirmation mail to the new address first.
5. Choose Change email. A message says “Email changed to
   ”.
6. Tell the person to sign in with the new address.

What it does not do

• It does not notify the old address. Tell the person yourself.
• It does not end their sessions, and it changes nothing else (roles, teams and history stay with the account).
• It changes the sign-in address and the Orbit profile together. Past audit entries keep the address that was current then.

What can go wrong

• “
  already belongs to another account.” Another account has it. Choose a different one, or deal with the other account first (section D).
• “The sign-in email was changed but Orbit could not save it. Send the same change again to finish.” Choose Change email again with the same address. It finishes the job.
• “Enter a valid email address.” or “That is already the email address.” Fix the typing.
• With Mark the new address as confirmed on, the System Admin who makes the change moves the account’s sign-in to the new address at once, without a mail to that address. Leave it on only when you are sure of the request. The change is audited with the old and the new address.

Values to record

None are secrets.

Key	Where found	Keep
Old and new address, who asked, when, how confirmed	Your own log, and Admin, System, Audit log (user.change_email)	Not secret, but personal data: keep it only as long as your retention rule says

D. Remove a person for good

There are two different actions. Choose by whether the account has history.

	Deactivate	Delete
What it does	Refuses the account and signs the person out of Orbit and the Stations. Teams, history and the audit trail stay.	Removes the account, its team memberships, run grants and settings.
When it is allowed	Always (not on yourself).	Only for an account without history.
Can it be undone	Yes: Reactivate restores the same teams.	No.
Use it for	Anyone who worked in Orbit, including people who left.	A mistaken invite, a test account.

What counts as history. An account has history when it ever started a run, appears in the audit log as the person who did something, owns or created an investigation, comment, release, requirement or other record, shared a saved view, or leads a team. Sign-ins alone do not count. Orbit counts these for you.

Prerequisites: a System Admin session verified with the authenticator. The person is not you.

Steps to deactivate

1. Admin, People and access, Users, select the person.
2. In the Danger zone of the Account tab choose Deactivate…, read “ is signed out everywhere, Stations included, and cannot sign in until reactivated. Teams are kept.” and choose Deactivate . (To do many people, tick them in the list and choose Deactivate in the bar.)
3. The state shows Deactivated.

Steps to delete

1. Open the person. On the Account tab, in the Danger zone, choose Delete user….
2. Read the dialog and type the person’s email to confirm. Choose Delete user. A message says “ was deleted”.
3. If Orbit answers “ cannot be deleted: the account has 12 audit entries, 3 runs. Deactivate it instead.”, the account has history. The list names what blocks it. Use Deactivate….

Reactivating

• Reactivate brings the account back with its teams. The person signs in with their usual password.
• While an account is deactivated Orbit refuses it at once, even if a sign-in token on some device is still valid.
• After Reactivate, refresh tokens issued before the deactivation can work again, because the sign-in service cannot end a person’s sessions by id and Orbit’s refusal is lifted. Reactivate only when you trust every device the person used. If a device was lost or stolen, ask the person to use Sign out other devices in Profile, Security straight after signing in.

What can go wrong

• The delete button is missing. You are on your own row.
• “The sign-in service could not delete the account. Nothing was changed; try again.” Wait and choose Delete user… again. If it keeps failing, ask the person who runs your Orbit installation to delete the account in the sign-in service, then try again here so Orbit removes its own rows.
• “This is the last active System Admin and cannot be deleted.” Make another person a System Admin first.

Values to record

None are secrets.

Key	Where found	Keep
Who was removed, why, when, who approved	Your own log	Not secret, personal data
The action	Admin, System, Audit log (user.deactivate, user.delete). A delete keeps the email in the audit entry.	Not secret

E. A person left the company

A checklist, in this order. Do it on the last day, or as soon as you hear.

Prerequisites: a System Admin session verified with the authenticator. Confirmation from the person’s manager or HR.

1. Deactivate the account: Admin, People and access, Users, select the person, Deactivate… (section D). From this moment Orbit refuses the account.
2. Review what they could do. Open Admin, People and access, Access, tab By person, pick the person. Note every project, role and team behind it, and the Run access entries on restricted environments.
3. Take over what they owned. Look at the work that needs an owner (open investigations, releases, schedules) with the project’s Project Admin. Orbit keeps history, so nothing is lost by deactivating.
4. Remove them from shared teams. Still on Users, open the Teams tab of the person’s sheet and choose the Remove from button (the ×) of each shared team chip. (Or Admin, People and access, Teams, Shared teams, open the team and remove the member.) If the person was the Lead of a team, the lead is cleared automatically when you remove them; assign a new one in the team’s Details and Save details if one is wanted. Project teams are not changed here.
5. Remove from projects. On Project settings, People of each project, choose Remove, then Remove from project. For a person who will never return, removing them is optional after deactivating, but it keeps the lists clean. The last Project Admin of a project cannot be removed: make another person a Project Admin first.
6. Revoke run access. Run grants are listed in By person. Remove each on the environment: Project settings, Environments, Edit on the environment, then Revoke next to the person under Run access to .
7. Check again. Access, By person: it should show no roles, or only what you chose to keep. Choose See changes for this person (it opens the Audit log filtered to the access events of that person) for the record.
8. Offboard elsewhere. Credentials the person knew (shared passwords of test accounts, API tokens) are not managed by this account. Change them where they live.
9. Delete only if there is no history. For a person who never did anything in Orbit, Delete user… is allowed (section D). Otherwise leave the account deactivated.

What can go wrong

• A deactivated person’s devices are refused at once, but see the note on reactivation in section D before ever reactivating them.
• The person owned a shared team’s lead role or a saved view shared with a project: both stay as history and block deletion, not deactivation.

Values to record

None are secrets.

Key	Where found	Keep
Leaving date, who confirmed it, steps done	Your own log	Not secret, personal data
The deactivation and team removals	Admin, System, Audit log, or Admin, People and access, Access, See changes for this person	Not secret

F. Periodic access review (quarterly)

Who has access to what, checked by a person who can say whether it is right. Do it every quarter, and after a reorganisation or an incident.

Prerequisites: a System Admin session verified with the authenticator. The project owners (Project Admins or the customer’s contact) available to answer.

Steps

1. Open Admin, People and access, Access and choose Export CSV (top right). The file is named orbit-access-<date>.csv. The export is itself audited (access.export, with the row count only).
2. Open the file in a spreadsheet. Read it with the columns below.
3. Walk each project with its owner: for each row, “should this person still have this role on this project?” Use By project on the Access page to see the same list live, with the team behind each role.
4. For each doubtful or outdated row, fix it: remove the person from the project (Project settings, People), change their role, remove them from a shared team (Teams or Users), or deactivate the account (section D or E). Re-run Export CSV after the fixes if you need a clean copy.
5. Look at the changes: choose See changes in the Access header (it opens the Audit log on the access events), set From to the day of the last review, and read each line (who changed what, when). See changes on this project, in By project, narrows it to one project. Anything you do not recognise is a question for the person named, or for the project owner.
6. Fill in the sign-off record below and file it with the (cleaned) export.

The columns of the CSV

One row per person and project.

Column	Meaning
person_email	The person’s sign-in address.
display_name	Their name in Orbit.
system_role	Member or System Admin.
project_slug	The project’s short name. Empty for the special rows below.
effective_role	The role they have on that project: the highest of all their teams on it (Viewer, QA Engineer, QA Lead, Project Admin).
source_teams	The teams that give that role, separated by ;.
account_state	active, grace (expired, view only for 3 days), expired or deactivated.
account_expires	The expiry date, or empty when the account never expires.
run_grant_environments	Restricted environments the person may run on (short names, separated by ;).

Two kinds of rows have empty project columns:

• System Admin rows. An active System Admin acts on every project with no team, so they get one row with effective_role set to system-admin (all projects) and nothing else in the project columns. If a team also gives them a role, the project rows follow it. Check that this list matches the people who should be System Admins.
• “No role” rows. An account that has no role on any project gets one row with empty project_slug and effective_role. These accounts can sign in but reach nothing. Decide for each: add them to a project, or deactivate (a person who left) or delete (a mistaken account).

Also look for: accounts in expired or deactivated that still hold roles; account_expires in the past or far in the future; a Project Admin who is a former employee; run grants on a restricted environment held by someone who no longer runs tests there.

Who must sign off. The System Admin who ran the review signs, and so does the owner of each project reviewed (a Project Admin, or the customer’s contact). A second System Admin countersigns when the review changed any System Admin. Keep the names and dates only.

What to keep and where. Keep the sign-off record and the cleaned CSV for the period your policy requires (put it in the place you keep other evidence, not in this repository: it holds email addresses). Note the date of the export; the audit log keeps the entry access.export for the same date. Do not paste the CSV into chat, tickets or the repo.

What can go wrong

• Export CSV is greyed out. The Access page has not loaded yet; wait a moment.
• “Verify your authenticator first”. Choose Verify now, then Export CSV again.
• A spreadsheet formula warning. Cells that start with =, +, - or @ are quoted by Orbit; open the file as plain text if your tool still warns.
• A person is missing from a project list. A role through an archived team does not count and is not listed. Check Admin, People and access, Teams, Show archived.

Values to record

The CSV holds personal data (names, emails) but no secrets.

Key	Where found	Keep
The CSV orbit-access-<date>.csv	Downloaded by Export CSV	Personal data, not secret. Keep with the sign-off, in your evidence store.
Date of review, who ran it, who signed	The record below	Not secret
The export entry	Admin, System, Audit log (access.export)	Not secret

Sign-off record (copy this table into your evidence store; leave personal data out of the repository)

Date	Reviewed by (System Admin)	Projects reviewed	Project owner sign-off	Changes made (count)	Countersigned by	Where the CSV is kept

G. Why can’t this person do X?

A person says “I cannot start a run” or “I cannot see this”. Explain answers with the same rules Orbit uses when the person tries.

Prerequisites: a System Admin session verified with the authenticator.

Steps

1. Open Admin, People and access, Access, tab By person. Pick the person in the Person box (search by name, email or job title).
2. Read the top: the System role, the Account state and Expires. A deactivated or expired account explains most complaints at once.
3. Read Projects: for each project, the role, the team behind it, and any “Run access on …”. No row for the project means no role there.
4. In Explain choose the Action. Actions are grouped In a project and Across Orbit. For a project action choose the Project; for starting a run also choose the Environment.
5. Read the answer. It starts with Allowed: or Not allowed: and gives the reason:

The reason says	What it means and what to do
“the account is deactivated”	The account was deactivated. Reactivate it on Users if that is right.
“the account has expired”	Past the 3-day view-only period. Set a new Account expires on Users (or Project settings, People for a person on one project only).
“the account has expired and is read-only for a few days; only viewing works”	In the grace period. Extend the expiry.
“System Admins may do this in every project”	The person is a System Admin: nothing blocks them.
“only a System Admin may do this”	A system action (users, teams, projects, Stations). Only System Admins. Change their Role on Users only if they should be one.
“this needs a project to be chosen”	Choose the Project in the form.
“no role on project ”	No team gives them a role there. Add them on Project settings, People, or put them in a team that has a role on it.
“needs QA Lead, has Viewer on project through team ”	The role is too low. Raise it on Project settings, People (if the team is a project team) or change the shared team’s role on Teams (Access to projects).
“restricted environment , no run grant (QA Engineer on project )”	The environment is restricted. Grant run access on the environment: Project settings, Environments, Edit, Grant someone….
“Project Admin on project … may run on restricted environment” or “… with a run grant on restricted environment”	Allowed, and by which role and team.
“QA Engineer on project through team ”	Allowed, and which team grants it.

6. If Explain says allowed but the person still cannot, the cause is on their side: a Station that is not signed in or is on an old version, a sign-in older than the change (ask them to sign out and in), or a different project chosen in the project switcher. A grant reaches the person’s Station within 5 minutes.
7. To see recent changes for this person, choose See changes for this person (opens the Audit log filtered to the access events of that person).

What can go wrong

• Explain shows no answer. Complete the form: a project action needs a project, and a run needs an environment.
• “Run grants without a role” notice: the person has run grants on a project where they have no role. They give nothing; add the role or remove the grants.
• System Admins appear in a notice, not in the lists. They have no team, by design.

Values to record

Nothing is secret and nothing needs keeping beyond your ticket.

Key	Where found	Keep
The question, the answer text and the fix applied	Your ticket	Not secret