Sign-in Methods & Policy
note
This information is only relevant for Admins managing a Playground Private Exchange.
Decide how people sign in to your Playground, and whether they may use anything other than your company identity provider. Everything is managed in one place: Control Panel → Advanced → Connections, in the Sign-in methods group.
The sign-in methods
| Method | What it is | Setup |
|---|---|---|
| Sign in with a Google account | A switch. Nothing else to configure | |
| Salesforce | Sign in with a Salesforce account | A switch (on by default) |
| SAML 2.0 | Your company identity provider (Okta, Microsoft Entra ID, OneLogin, ...) | SAML 2.0 setup |
| OpenID Connect | Any OpenID Connect provider | OpenID Connect setup |
Select a card and choose Set up, Manage or Change to open its settings. The question-mark icon on every card opens the matching guide.
note
Single sign-on (SAML 2.0 and OpenID Connect) must first be made available for your Playground under Control Panel → General → Advanced Features (Enable SAML SSO / Enable OpenID Connect SSO). The cards then appear in Connections.
Google and Salesforce
Open the Google or Salesforce card and use the switch to show or hide that option on your login and sign-up pages.
- Turning Salesforce off only affects signing in. Deploying, validating and installing plays into Salesforce orgs keeps working.
- At least one sign-in method must stay on, so nobody is locked out. Playground will not let you turn the last one off.
- If a method is turned off, it is refused on the server as well, not just hidden from the page. Administrators are the one exception, so a change can never lock every admin out.
Require single sign-on
By default, people can use any method that is turned on. If your company wants to enforce its identity provider, open the Sign-in policy card and choose Single sign-on only.
| Policy | What happens |
|---|---|
| Any sign-in method | Every method that is turned on works (default) |
| Single sign-on only | People must sign in through your identity provider. Google and Salesforce sign-in stop working for them, and the Sign up link is hidden. If you have a single identity provider, the login page sends people straight to it. |
Protection against lock-out
Switching to single sign-on only is checked first:
- At least one single sign-on connection must be enabled.
- You must have signed in with single sign-on in the current session. Test it from a private window first, then come back and switch the policy. This proves the connection works before it becomes the only way in.
Administrators and emergency access
- Administrators are always allowed. Anyone whose role can manage settings can still sign in with Google or Salesforce, so a problem at your identity provider can never lock every administrator out.
- Additional emergency access emails (optional) let named non-administrators do the same. Enter one email per line.
- The emergency page
https://<your-playground>/login?local=1shows every method, and is where those people sign in.
What is not affected
Single sign-on only governs people signing in. These keep working:
- Connecting a Salesforce org to deploy, validate or install a play.
- App passwords used by the VS Code extension and MCP.
Reporting on sign-in problems
Failed sign-ins are written to the login history with a short message you can use in reports, for example:
| Code | Meaning |
|---|---|
SSO_REQUIRED | The domain requires single sign-on and the person tried another method |
SSO_NO_ACCOUNT | Signed in at the identity provider, but no account exists and automatic account creation is off |
LOGIN_METHOD_DISABLED | The sign-in method is turned off for this domain |
NO_WORK_EMAIL | The email does not belong to this domain |
USER_INACTIVE | The account is inactive |
The SAML and OpenID Connect guides list the codes specific to those connections.