SSO launch checklist
Verify company sign-in works, and that access removal works, before you switch your team over.
2 min read
Verify these before you make company sign-in the way your team reaches OmniLab. The failure mode here is locking out the people who run your campaigns, so test the recovery path as carefully as the happy one.
Test sign-in
- A colleague in scope signs in with their company account and reaches OmniLab Studio.
- They land with the access their role allows — not more, and not an empty screen.
- Someone who is not in scope is refused cleanly, with a message rather than a loop.
- Sign-in works from outside the office network, if your team works remotely.
- Sign-in works on a phone, if anyone reviews campaigns from one.
Test access removal
This is the part that is usually assumed and rarely tested, and it is the one an audit will ask about.
- Disable a test colleague's company account and confirm they lose OmniLab access.
- Confirm how quickly that takes effect — immediately, or when their current session expires.
Test the recovery path
- Confirm at least one administrator can still sign in if the identity system is unavailable.
- Write down who that is and how, somewhere your team can reach without OmniLab.
Before you switch everyone
- Tell your team what changes and what the sign-in button now looks like.
- Agree who they contact if sign-in fails on the day.
- Consider moving one department first — a staged rollout is far easier to reverse.
Where to send a problem
| What is happening | Who to contact first |
|---|---|
| Sign-in fails for everyone | Your identity team — check the application registration first |
| Sign-in works but the person lands with no access | Your OmniLab administrator — this is a role assignment, not SSO |
| One person cannot sign in, others can | Your identity team — usually a scope or group membership |
| Someone who left still has access | Your identity team, then OmniLab support |