Overview
Single sign-on will connect the PreStartGo admin console to your company's identity provider — Entra ID, Okta, Google Workspace, or any provider speaking SAML 2.0 or OpenID Connect — so your office users sign in with their corporate identity, under your IT team's policies.
Note
SSO is coming, and isn't switched on yet. Today every console user signs in with email, password and multi-factor authentication — see Signing In and MFA. If SSO matters to your organisation, talk to us and we'll keep you posted.
SSO will come with the SSO + data residency add-on, on any paid plan. This article describes how it will work, so your IT team can plan ahead.
Before you start
- Plan
- Any paid plan, with the SSO + data residency add-on, once SSO is switched on
- Role
- Account Owner to arrange it; your IT team for the identity-provider side
- An identity provider supporting SAML 2.0 or OIDC
How setup will work: configured with you
There will deliberately be no SSO settings page to fill in yourself. Identity federation is a security-critical integration where a misconfiguration can lock out an organisation or, worse, quietly weaken sign-in — so PreStartGo will configure it with you:
- 1Contact the team with your identity provider's details.
- 2
We'll exchange the federation metadata with your IT team — the same certificate/endpoint exchange they'll have done for other SAML or OIDC applications.
- 3
Sign-in will be checked together with a test user before the switch applies to the organisation.
What will change for your users
- Console users will sign in through your identity provider — corporate password, corporate MFA, under your IT team's rules.
- Joiners and leavers will follow your directory — disabling someone in your IdP ends their console sign-in.
- Field operators are unaffected. The mobile app's phone-number sign-in isn't email identity and won't route through corporate SSO — operators keep the SMS-code flow. See Signing In and MFA.
Edge cases
- Until SSO is switched on — console users sign in with email, password and MFA, as they do today.
- A mixed console — during rollout, existing password users will continue until the cutover is agreed; the switch will be coordinated, not a surprise.
- IdP outage — console sign-in will follow your IdP's availability, as with any federated application. The field keeps working regardless: operators don't sign in through the console.
- API keys are unaffected — machine credentials aren't user sign-ins. See Authentication and API Keys.
Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| No way to sign in with SSO | SSO isn't switched on yet | Sign in with email, password and MFA; ask us about timing |
| Looking for the SSO settings page | There won't be one — it's set up with you | Talk to us |
| Operators asking about SSO | Field sign-in won't use it | Phone + SMS code, unchanged |