Company sign-in (SSO)
Let your team log in to OmniLab with their existing company account instead of a separate password.
Let your team sign in to OmniLab with the company account they already use, so there is no separate OmniLab password to manage. This page is for admins and IT teams setting up single sign-on (SSO), where OmniLab connects to your organisation's existing identity system, such as Microsoft Azure or Salesforce. Users click one button and they are in.
SSO is set up by your Customer Success Manager
You do not configure SSO yourself. Contact your Customer Success Manager, share the details your IT team has prepared, and OmniLab will enable the provider for your environment.
Supported providers
| Provider | Best fit |
|---|---|
| Microsoft Entra ID (Azure Active Directory) | Organisations that already use Microsoft for identity |
| Salesforce Marketing Cloud | Teams managing identity via Salesforce |
| Custom enterprise provider | Any company identity system that follows standard sign-in protocols |
If you need a provider not listed here, ask your Customer Success Manager before planning your rollout.
What your IT team needs to do
Your IT team will register OmniLab as a trusted application in your company's identity system and gather a small set of credentials to share. The exact steps depend on the provider you use.
Hand this to your developer or IT administrator: SSO / OIDC setup reference. OIDC (OpenID Connect) is the technical protocol most identity providers use to support single sign-on.
That guide covers the exact fields to collect per provider, where to find them in each admin console, and a pre-launch checklist.
What to prepare on the OmniLab side
Before testing sign-in:
- Make sure each test user already exists in OmniLab.
- Assign each test user to at least one organisation in OmniLab.
- Use the same email address in OmniLab as the one the identity provider will return.
- Set each test user's sign-in method to company single sign-on. Only an Admin can do this, and until it is done the user is refused with a Wrong sign-in method message.
Rolling out gradually
Every account is tied to exactly one sign-in method, so switching a user to single sign-on is what actually moves them — and it moves them completely. There is no per-user fallback: once someone is assigned single sign-on, the email link no longer signs them in, even when email sign-in stays enabled for the environment.
That makes the rollout a per-user migration rather than an environment-wide switch:
- Leave email sign-in enabled for the environment.
- Move a small pilot group to single sign-on and confirm they land in the right organisation.
- Move the rest in batches once the pilot is clean.
- Ask your Customer Success Manager to turn email sign-in off only after everyone is migrated.
If a pilot user gets stuck, an Admin can put that one account back on email sign-in — that is the rollback, rather than anything at the environment level.
Turning a method off blocks the users assigned to it
Disabling email sign-in while accounts are still assigned to it locks those users out. Move them to single sign-on first, then disable the method.