What your identity team provides
Gather the details OmniLab needs to trust your identity system, before anyone starts configuring.
Collect these before your first configuration call. SSO projects rarely run late on the technical work. They wait on one value from a team nobody asked.
Who to involve
- Whoever administers your identity system (Microsoft Entra ID, Salesforce, Okta or similar). They need permission to register a new application, and they're often not the person who uses it.
- Your Customer Success Manager, who turns on SSO for your environment.
- Whoever decides which colleagues get which access in Studio.
What to collect
| What | Why it's needed | Who has it |
|---|---|---|
| Your identity provider and how it's hosted | Decides which setup applies | Your IT team |
| The application registration in your identity system | What OmniLab authenticates against | Your identity administrator |
| The sign-in addresses people return to | Your identity system refuses any address not on its list | Agreed with OmniLab |
| Which user attributes are shared at sign-in | Decides what OmniLab knows about a person | Your identity administrator |
| The email domains in scope | Decides who SSO applies to | You |
The field names differ by provider. Connect your identity provider lists them for Microsoft Entra ID, Salesforce Marketing Cloud and another OAuth 2.0 provider.
Decide before you configure
Who's in scope. All colleagues, or one department first? A staged rollout is easier to reverse.
How existing accounts move over. Colleagues who sign in by email today are moved one account at a time, with their Authentication Provider. The email on their Studio account must exactly match the one your identity system returns. If it doesn't, sign-in fails with User not found.
Who can sign in if SSO breaks. Keep at least one administrator on email sign-in: their Authentication Provider stays on email, and your Customer Success Manager keeps email sign-in on for your environment. Otherwise an outage at your provider locks everyone out of Studio too.
Test that access removal works
The main benefit is that disabling someone's company account removes their Studio access. Check with your identity team that this happens in your setup. Auditors ask about it, so test it rather than assume it.