Single Sign-On (SSO) allows users to access Wello using the same work account they use for other company systems (for example, Microsoft Entra ID, Google Workspace, or Okta).

Instead of creating and managing a separate Wello username and password, users are redirected to their company’s login page, where their identity is authenticated. Once successfully authenticated, they are granted access to Wello without needing to log in again.

Wello uses WorkOS as a secure bridge between Wello and the company’s Identity Provider (IdP).

SSO is available only for customers on the Enterprise license plan and must be enabled in Wello. Users who log in via SSO do not have a Wello password. Their access is fully managed by the company’s Identity Provider, allowing administrators to control access by managing users and groups within the company directory (for example, Microsoft Entra ID).

SSO is especially useful when:

• There might be one account and password for Wello
• And another account and password for email
• And more for other tools

• Users log in to Wello with the same account used for company email or other internal systems.
• The company’s own sign-in system approves who can enter Wello.
• Access is controlled in one central place.

In practice, this means: Less hassle for users, who no longer need to remember an extra password and easier control for the organization, because when an employee leaves or changes role, it is managed once in the company system, and this change is also reflected in Wello.

When a user wants to log in to the Wello Portal:

So, Wello does not check the user’s password directly. The company system does. Wello trusts the system once it confirms the person is allowed in.

If the company does not use SSO, the user is taken to the normal Wello password screen instead.

From the user’s point of view, SSO mainly changes how the login process starts and how many passwords need to be remembered.

When SSO is set up for a company, the user goes to the Wello login page. On the first screen, the user is asked to type their work email address. After typing the email, the user clicks continue. From there, Wello checks whether that email belongs to a company where SSO is turned on or not, and Wello decides which path to follow.

If Wello sees that the email belongs to a company that does not use SSO:

• The user is taken to a second screen where a Wello password is entered.
• This is the “classic” login: email + Wello password.

If the email belongs to a company that uses SSO:

• The user is redirected from Wello to the company’s own sign-in page (for example the Microsoft Entra ID sign-in page).
• The user signs in there with the usual details.
• If already signed in on that device, no sign-in form may appear, and access continues directly back into Wello.
• Once approved, the user lands in the Wello Portal as normal.

Prerequisites

Before SSO can be enabled:

• The Wello implementation must be on the Enterprise license plan.
• The user to enable it must have an Administrator right in the Wello Portal (belonging to the administrator group).
• Your IT must be ready to configure the Identity Provider (Azure AD, Okta, Google Workspace, etc.) in the WorkOS portal.

In the Wello Portal, go to Settings in the top right corner and select Get Started. Select the General Settings tab, and in the Single Sign-On settings section, turn on the “Enable Single Sign-On” option.

A new SSO configuration area appears, with:

Note: This setting is only available if the company is on the correct subscription (Enterprise Plan) and SSO has been activated or enabled.

The Allowed domains tell Wello and WorkOS which email domains are permitted to use SSO in the organization.

Typical examples:

Enter the domain in the Allowed Domains field and click the add button. Multiple domains can be added to the same organization if several regional domains are used, such as fr.gea.com, be.gea.com, etc.

These domains tell Wello: “When an email ends with this domain, try to log in this user with SSO.”

You can also delete unused domains using the bin or trash icon in front of each added domain to prevent SSO login from those email domains. When doing so, Wello asks for confirmation and warns that users with those email addresses can no longer log in via SSO. They would need to use a normal Wello password (if that is allowed and configured for them).

Once at least one verified domain is available, the SSO connection can be configured:

While this setup is in progress, the SSO section under Identity Provider in Wello shows the “Continue Setup” button, clearly indicating that the setup is not yet finished and allowing continuation. Wello regularly checks the connection status (every 30 seconds) and automatically refreshes the status in the SSO settings.

Once the IdP is fully configured and verified in WorkOS, Wello updates the SSO settings to show the name of the Identity Provider, for example “Entra ID (Azure AD)” or “Okta”.

The SSO connection is now active and ready to use. Users with emails from allowed, verified domains and who are correctly assigned in the identity provider can now log in via SSO.

Let us walk through a typical day for an end user after SSO is enabled.

On later days:

When an employee leaves the company and the IT team turns off the work account: The user can no longer sign in to the company sign-in system. Because Wello trusts that sign-in system, that person can no longer access Wello.

If Directory Sync is also turned on (explained below), Wello will clearly mark this person as inactive in the Wello user list so managers can archive them.

In addition to SSO, there is a separate optional feature that helps keep user status in Wello aligned with the directory. In simple terms, this is:

A way for Wello to be informed when a user has been turned off, removed, or re-enabled in the Identity Provider, so managers can act accordingly in Wello.

This is very useful when:

Example: Entra ID (Azure AD) is used for SSO, and there is still a need for Wello to know when someone is no longer active in the directory.

A “Directory Sync” setting is available under the “Single Sign-On” section in the Organization General Settings tab when SSO is enabled. When “Setup Directory Sync,” is selected, Wello opens the WorkOS Directory Sync setup in a new tab.

After completing setup and starting synchronization, WorkOS sends Wello events Whenever a user:

For each such event, Wello:

For example:

If a user is disabled or removed from the SSO-enabled group in the company system (Identity Provider), Wello marks the contract end date as being in the past. The user is highlighted in red in the Wello user list, and once archived through the Wello Portal, access to Wello is no longer possible.

This keeps Wello aligned with the directory while still allowing Wello managers to control the final archiving step inside Wello.

Note: Provisioning intervals (how often the IdP syncs changes) depend on the IdP. For example, Azure AD may sync every 40 minutes (this means that if a user is turned off or removed, it can take up to around 40 minutes before Wello highlights the user in red), so there may be a delay between a change in the directory and the corresponding update in Wello. This is normal and depends on how often the company system (IdP) sends updates.

Also, an organization must complete the Identity Provider setup first before they are able to setup Directory Sync.

While this setup is in progress, the SSO section under Directory Sync in Wello shows the “Continue Setup” button, clearly indicating that the setup is not yet finished and allowing continuation. Wello regularly checks the connection status (every 30 seconds) and automatically refreshes the status in the SSO settings. Once the IdP is fully configured, Wello updates the Directory Sync to show the name of the Identity Provider.

Wello supports changing the provider. It is possible to move from one Identity Provider (IdP) to another (for example, from Okta to Entra ID). Once SSO has been configured, there is a “Change” button in the SSO settings beside the selected Identity Provider.

When selecting this option, Wello shows a warning (“Your SSO connection will be updated to a new Identity Provider. Please ensure existing users are migrated to maintain access. Do you want to continue?”) to ensure all users are migrated to the new IdP.

If confirmed:

If users are not correctly migrated, they will no longer be able to log in via SSO until the IdP configuration is corrected.

Sometimes SSO might be turned off, for example if the company changes its subscription level or decides to stop using SSO. In such cases, Wello does not simply block all users.

When SSO stops for theorganization, there are two main cases:

When downgrading in the subscription page or via Wello Sales Support, Wello shows a clear warning.

If confirmed, Wello:

• Deletes the SSO connection and organization in WorkOS.
• Generates random passwords for active users who previously had no password.
• Emails each such user a default password and a link to update the password.

When SSO is switched off in the portal, a similar warning is shown.

If confirmed, Wello performs the same steps (users receive an email with information and a temporary password so they can still sign in directly) to keep access possible by reverting to password-based login.

From a security perspective, this ensures that users are not locked out and that no user remains in a broken state where neither SSO nor a usable password is available.

When implemented correctly, SSO is generally considered more secure than separate username and password login for each application. In the Wello + WorkOS setup, SSO offers:

When used correctly, SSO is generally more secure than having separate usernames and passwords for each system.

Like any system, SSO must be configured and maintained carefully, if the Identity Provider is misconfigured, users might not be able to log in, or in the worst case, access could be incorrectly granted. Wello relies on the IdP configuration, but also:

If SSO is disabled suddenly (license downgrade or settings change), SSO users might lose access. Wello handles this by generating safe temporary passwords and emailing users instructions to set a new password.