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.
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 must first be made available for your Playground under Control Panel → General → Advanced Features, with Enable SAML 2.0 (SSO) and/or Enable OpenID Connect (SSO). The cards then appear in Connections.
Card status
| Status | Meaning |
|---|---|
| Not set up | Nothing saved yet |
| Configured - disabled | Details are saved, but the sign-in button is not shown. Use this to test before anyone sees it |
| Enabled | The sign-in button is shown on your sign-in page |
Google and Salesforce
Open the Google or Salesforce card and use the switch to show or hide that option on your sign-in 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.
- A method that is turned off 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. To make your identity provider the only way in, open the Sign-in policy card and choose Require single sign-on (SSO).
| Policy | What happens |
|---|---|
| Any sign-in method (default) | Every method that is turned on works |
| Require single sign-on (SSO) | People must sign in through your identity provider. Google and Salesforce sign-in stop working for them and the Sign up link is hidden. With a single identity provider, the sign-in page sends people straight to it |
Who can still use Google or Salesforce when SSO is required
| Who | Can use Google or Salesforce? |
|---|---|
| Anyone whose role has Manage Settings (administrators) | Yes, always |
| People listed under Break-glass accounts | Yes |
| Everyone else | No. They must use single sign-on |
Break-glass accounts are an optional list of emergency access emails for non-administrators. Enter one email per line. Break-glass sign-in is done on this page, which shows every method: https://<your-playground>/login?local=1
Protection against lock-out
Playground checks two things before it lets you switch to Require single sign-on (SSO):
- At least one single sign-on connection is enabled.
- You signed in with single sign-on in your current session, within the last 24 hours. Test from a private window first, then return and switch the policy. This proves the connection works before it becomes the only way in.
What is not affected
The policy governs people signing in only. These keep working:
- Connecting a Salesforce org to deploy, validate or install a play.
- App passwords used by the VS Code extension and MCP.
- The public API.
Common setups
| I want… | Set this |
|---|---|
| Google and Salesforce only (today's default) | Leave single sign-on off. Policy: Any sign-in method |
| Single sign-on plus Google and Salesforce | Set up SAML 2.0 or OpenID Connect and enable it. Policy: Any sign-in method |
| Single sign-on only | Enable your SAML 2.0 or OpenID Connect connection, sign in with it once, then policy: Require single sign-on (SSO) |
| People to be created automatically | On the connection: Just-in-time (JIT) provisioning on |
| Only people I added to get in | On the connection: Just-in-time (JIT) provisioning off |
| To test SSO without anyone seeing it | Save the connection but keep Enable … (SSO) off. Test with the link shown by Test configuration |
| To get back in if SSO breaks | Sign in as an administrator or break-glass account at /login?local=1 |
Allowed email domains
On a private Playground, every sign-in method also checks the person's email against your Allowed Email Domains. This is separate from the sign-in policy: the policy decides how people sign in, the domain list decides who may.
Reporting on sign-in problems
Failed sign-ins are written to the login history with a short message you can use in reports:
| Code | Meaning |
|---|---|
SSO_REQUIRED | The policy requires single sign-on and the person tried another method |
SSO_NO_ACCOUNT | Signed in at the identity provider, but no account exists and JIT provisioning is off |
LOGIN_METHOD_DISABLED | The sign-in method is turned off for this domain |
NO_WORK_EMAIL | The email is not on the allowed email domains (General) |
SSO_UID_NOT_FOUND | No person has the Unique ID sent by the identity provider (People page) |
SSO_UID_EMAIL_EXISTS | A person with this email exists but has a different or empty Unique ID |
USER_INACTIVE | The account is inactive |
The SAML 2.0 and OpenID Connect guides list the codes specific to those connections.