How your team signs in is yours to set: an email address and password, Google or Microsoft, or your company's own identity provider. You'll find those choices under Admin → Authentication security, along with directory sync for keeping your user list in step with your provider. The Owner and Admins can open that page. You can also give a custom role the Manage authentication security permission.

If your team should only be signing in one way, this is where you say so. The Login methods section has a checkbox for Email and password and one for Google and Microsoft: check the ones you want, then click Save settings. Google and Microsoft share a checkbox, so you can't allow one without the other.

A new workspace starts with both allowed. At least one has to stay checked.

You can also give one person their own setting:

On the Users list, the Authentication column reads Custom methods for anyone on their own setting.

Your choices don't change the sign-in screen. Every option stays visible there, and if someone picks a method you've turned off, they'll get a message naming the ones they can use.

Once you connect single sign-on, these checkboxes stop covering everyone: they apply to the people who can still sign in without it. That means all of your team while single sign-on is optional, and only the people you exempt once you require it. Both of those are choices under SSO enforcement.

If your company already runs an identity provider, your team can reach Simplesat through it, under the access rules and multi-factor policy you keep there. Single sign-on comes with Enterprise, and it supports both SAML and OIDC, so Microsoft Entra ID, Google Workspace, Okta, Auth0 and custom setups all work. The buttons all say SSO.

To set it up:

That's all it takes to connect. A green Active label on the section means your provider is connected and sign-ins work straight away. If they aren't going through, start a chat and we'll look at the connection with you.

Only one domain is authorized. It's the one you set up during configuration, and if you need another, start a chat and we'll add it to your list.

Once single sign-on is connected, you get an Authorization URL. Share it with your team and they can create their own Simplesat accounts without an invitation, as long as they're on an authorized domain. They arrive with the Collaborator role, and you can change that on the Users page.

Under SSO enforcement, you choose who has to use it:

Enforcement doesn't change the sign-in screen either. If someone tries their password anyway, they're told to use single sign-on instead.

Nothing changes for anyone until their next sign-in. Nobody is signed out, and your team stays in until their current sessions expire. If one person needs a password elsewhere, open them on the Users page and check Disable SSO enforcement, which sticks even if you change the workspace-wide choice later.

To see where everyone stands, check the Authentication column on the Users page: it reads SSO enforced or SSO optional for each person.

When someone joins your company or leaves it, you'd rather not do the work twice. Directory sync, available on Enterprise, keeps your Simplesat users in step with your identity provider. Joiners and leavers get handled where you already handle them.

Click Configure directory sync and follow the steps the portal gives you. A sync takes a few minutes to finish. You can share the Authorization URL at the same time: there's no order to follow, and people can arrive either way.

Use Edit group mapping to connect your provider's groups to Simplesat roles: that mapping decides what role people arrive with. If one of your people is in two mapped groups, they get the role with the most permissions. When a role looks wrong after a sync, start there.

That's expected. The password box stays on the sign-in screen, and the attempt is refused with a message pointing them at single sign-on. If that person genuinely needs a password, open them on the Users page and check Disable SSO enforcement.

If your own workspace doesn't require single sign-on and this still happens, another Simplesat workspace they belong to does, and its requirement reaches into yours. Start a chat and we'll help you find which one.

When it works for part of your team and not the rest, the usual cause is assignment on your provider's side. Check that the people who can't get in are assigned to the Simplesat application in your identity provider.

If they're all assigned and it's still happening, send us the affected email addresses and roughly when it started.

What to do next depends on what your team is seeing. Start a chat and tell us what's on the screen, whether it hits everyone or only part of your team, and roughly when it started. We'll take it from there.

Check the Authentication column on the Users page for that person. If it reads Custom methods, they're on their own setting instead of the workspace default, so the change you made didn't reach them.

Then look at the other workspaces they belong to. A method only works for someone if every workspace they belong to allows it.

Requiring single sign-on does. It follows the person. Anyone you require it for has to use single sign-on everywhere they work in Simplesat, including workspaces that have no single sign-on of their own. Login methods reach across workspaces the same way: a method has to be allowed by every workspace someone belongs to before they can use it in any of them.

Yes. Turning the requirement off doesn't remove anyone's password, it only changes what's accepted at sign-in. Set SSO enforcement to It's optional and your team can sign in with whatever the Login methods section allows.