Protect your account with two-factor authentication, and let your team sign in through your organization's identity provider.
With two-factor authentication on, signing in takes your password and a six-digit code from an authenticator app on your phone, such as Google Authenticator, Microsoft Authenticator, 1Password or Authy. Someone who learns your password still cannot get in without your phone.
To turn it on, open your Profile from the account menu and choose Two-factor authentication. On UniversalDesk, choose Two-factor authentication from the account menu. Scan the QR code with your authenticator app, enter your password and the code the app shows, and you are set. We email you whenever two-factor authentication is turned on or off for your account.
Turning it on signs you out everywhere else, including the inbox app on your other devices, so each one is signed in again with a code.
From then on, after your password you are asked for the current code. A browser you have used recently remembers your password but still asks for a code when you come back to it.
When you set up your authenticator app you get a set of recovery codes. Each one works once, in place of a code from the app, so you can still sign in if you lose your phone. Confirm your password to see them right after setup, and keep them somewhere safe, such as your password manager.
To sign in with one, choose Use a recovery code where you are asked for the code. You can see your remaining codes, or make new ones, from the same place you turned two-factor authentication on.
Five wrong codes in a row lock your authenticator app for sign-in, and we email you. To unlock it, enter three correct codes from the app in a row, a short wait apart, or sign in with a recovery code.
Two-factor authentication can be required for everyone in the workspace, on every plan. In UniversalChatbot the owner and managers can require it under Settings → Security → Sign-in security. In UniversalDesk only the owner can, at the same place. Turn on Require two-factor authentication. You need it on your own account first.
Once it is required, anyone opening the workspace without it is asked to set it up before they can go further. That includes the inbox app, which tells them to set it up from a browser and sign in again. People who sign in with your identity provider have already passed its checks, so they are not asked for a code as well.
Single sign-on lets your team sign in with the account they already use at work, through your identity provider, instead of a separate password. Any provider that speaks SAML 2.0 or OpenID Connect works, including Microsoft Entra ID, Okta, Google Workspace, OneLogin, Ping Identity and Active Directory Federation Services. Your provider's own rules, such as its two-factor checks and conditional access, then apply to signing in here.
Single sign-on is included on the UniversalChatbot Business plan. UniversalDesk does not offer it.
Open Settings → Security → Single sign-on in your dashboard. Choose SAML 2.0 or OpenID Connect, then give your provider's admin the details shown on the page:
Turn on Single sign-on and save. People can sign in through your provider as soon as your domain is verified.
Before your team relies on it, choose Test sign-in on the same page. You sign in at your provider as usual, and we show the email it confirmed and whether that person would be let in, without signing anyone in here. If your provider's answer is not accepted, for example because of a wrong client secret or certificate, the test shows the exact reason. You can test before turning single sign-on on.
Your provider can sign in people whose email address is on a domain you have verified, and nobody else. This is what stops a provider from speaking for an address that is not yours.
Open Verified domains next to it, add the domain in your team's email addresses, such as example.com, and add the TXT record shown to that domain's DNS. We look for the record every 15 minutes for a week after you add the domain, and email your owner and managers as soon as it is found. To check straight away, choose Verify. If the record is not there yet, the page tells you, and you can try again once your DNS change has spread. Keep the record in place once the domain is verified. We check it every day, and if it goes missing your owner and managers are emailed. A domain whose record is still missing two weeks later stops being verified, and if it was your last verified domain, single sign-on stops being required so nobody is locked out.
A domain can be verified by one workspace at a time. Add each domain your team uses.
Turn on Require single sign-on and everyone opening the workspace must have signed in through your provider. Someone who signed in with a password is sent to your provider first. You need at least one verified domain before you can require it. While it is required, your last verified domain cannot be removed. Turn the requirement off first.
The owner always signs in with their password, never through your provider, so a problem with your provider never locks you out of fixing it. If your plan changes to one without single sign-on, your team goes back to signing in with their passwords. Anyone who joined through your provider and never had a password sets one with Forgot password? on the sign-in page.
People on your team whose email address is not on a verified domain cannot sign in through your provider. While single sign-on is required, they cannot open the workspace either.
Sign in through your provider again sets how long a sign-in through your provider lasts while single sign-on is required, from every 4 hours to every week. After that, people go back through your provider, which turns away anyone you have removed there. This ends their browser and app sessions; their API tokens keep working until they are suspended or removed here, by you or by your provider through SCIM. Leave it at Only when the session ends to keep people signed in until they sign out or stay away for two weeks.
By default, only people already in the workspace can sign in through your provider. Turn on Add new people automatically and anyone on a verified domain who signs in through your provider joins the workspace as a member, as long as a seat is free. They join without builder or knowledge manager, which a manager can give them afterwards. Everyone else is told to ask the workspace owner or a manager for an invitation.
To take someone's access away, remove them in your provider and suspend or remove them here, or let your provider do both with SCIM. A suspended person cannot sign in through your provider either.
With SCIM, your identity provider adds people to the workspace when you assign them the app there, and takes their access away the moment you unassign or disable them. It works with providers that support SCIM 2.0, such as Okta, Microsoft Entra ID and OneLogin. Google Workspace does not offer SCIM for apps like this one, so when you remove someone there, suspend or remove them here too.
On the Single sign-on page, choose Generate SCIM token and copy the token, which is shown once. In your provider, turn on provisioning for the app and enter the SCIM base URL from the same page with the token. Generating a new token stops the old one working.
Your provider and your owner and managers each have a say, and both have to allow access. You can still suspend someone your provider manages, and your provider cannot lift that. Reactivating someone here does not override your provider: if it removed them, they stay without access. Members your provider manages are marked on the members page, which also shows who suspended someone and why. The reason is optional when the owner or a manager suspends someone; when the workspace suspends someone itself, for example because no seat was free, it says so.
To manage someone here again, choose Stop provider management on their member page. Choosing Turn off SCIM, or turning single sign-on off, does that for everyone. Anyone your provider had removed stays suspended.
Signing in starts with your email. Enter your work email and choose Continue: if it is on a domain your organization has verified for single sign-on, you go straight to your organization's sign-in page and come back signed in. Any other email is asked for its password. If you were already signed in with your password and the workspace requires single sign-on, you are taken through your provider when you open it.
To use a password on a single sign-on domain, for example as the owner while your provider is down, choose Use a password instead under the email.
The inbox app signs in the same way: enter your email, and a single sign-on email opens your organization's sign-in page and returns you to the app when you are done. Otherwise it asks for your password, then your code when your account has two-factor authentication, with Use a recovery code there too.
A workspace has four roles, and each can do everything the roles below it can:
Whoever sets up single sign-on decides which identity provider can sign in your team, so the owner and every manager are emailed whenever its settings change.