SSO Access Policy requires a Business or Enterprise plan. View plans
Where It Lives
The Access Policy sits at the top of the SSO settings page (useinvent.com/o/settings/sso). It’s a two-toggle form that saves automatically as you change it, no save button needed.Policy Toggles
Allow Google sign-in
When on, users on your verified domain can sign in using Google. When off, Google sign-in is rejected with a message asking them to use SSO.Allow email code sign-in
When on, users on your verified domain can sign in using a one-time email code. When off, email-code sign-in is rejected with a message asking them to use SSO.When Does the Policy Apply?
The policy only has an effect when both of these are true for the user trying to sign in:- Their email domain matches a verified SSO domain on your org.
- Your org has at least one enabled SSO profile.
acme.com if no SSO option is actually set up. Configure the profile first, then tighten the policy.
Typical Setups
SSO + alternatives
Both toggles on. Users see SSO as the preferred option but can still sign in with Google or email code if they prefer.
Good for: mixed workforces, gradual SSO rollouts, preserving legacy accounts.
SSO only
Both toggles off. Your team must use SSO. Every other method is blocked for emails on your domain.
Good for: strict security postures, SOC2 / ISO 27001 compliance, regulated environments.
SSO + Google
Allow Google on, email code off. Users must use a managed identity (either SSO or Google), but one-time codes are blocked.
Good for: Google Workspace customers who want Google sign-in as a backup.
SSO + email code
Allow Google off, email code on. One-time codes stay as a backup path in case your IdP is down.
Good for: resilience, since email codes work even when your IdP has an outage.
Safety Rails
”No login methods allowed” warning
If you turn both toggles off while SSO is configured, Invent shows a warning right in the settings UI. Even though this is a valid configuration (SSO will still work), it means SSO is the only way in for your team. The warning is a reminder to double-check that SSO is working end-to-end before committing.Verified domain notice
The Access Policy card shows a small notice explaining that the policy only applies to users on verified domains. Visitors without a matching email domain aren’t affected by these toggles.Changing the Policy
Toggles save as you flip them. There’s no separate save button. Changes take effect on the next sign-in. Existing sessions are not revoked automatically.Dedicated session revocation controls are coming soon. In the meantime, existing sessions stay active until they expire on their own or the user signs out.
How It Relates to Other Settings
- SSO Domains define who the policy applies to (users whose email matches).
- SSO Profiles define what SSO connection they use once you send them down that path.
- Access Policy defines what alternatives they have besides SSO.
Session TTL
In addition to login-method toggles, the Access Policy governs session lifetime for SSO logins. By default sessions never expire; you can set a maximum lifetime (in seconds) so that SSO-authenticated sessions force re-authentication periodically. This is useful when your IdP enforces session policies of its own and you want Invent sessions to renew at a similar cadence.Session TTL applies to new SSO sessions going forward. Existing sessions keep their original expiry.