SSO and Directory Sync
Staff can sign in to BloomText with Okta, and Okta can add, change and remove them automatically through Directory Sync. This page is for IT teams deciding how single sign-on (SSO), Directory Sync and the members API fit together. The setup steps are in the admin help: Okta setup guide for IT and Set up single sign-on .
Identity providers
Okta first; Microsoft Entra ID, Google Workspace and other SAML/SCIM directories through the same WorkOS setup, turned on when you ask.
An account connects one identity provider. BloomText uses WorkOS for SSO and Directory Sync, so your IT team sets up a SAML app and a SCIM directory in Okta through WorkOS’s setup portal; there’s no Okta Integration Network tile to install.
How it’s turned on
- BloomText turns on SSO for your account.
- An Owner or IT person opens Settings → Account → Okta & rules in BloomText and clicks Set up in WorkOS. The setup portal walks them through verifying your email domain, adding BloomText to Okta as a SAML app, and connecting your Okta directory (SCIM).
- They write rules that decide where people go (below), then assign people or groups to the BloomText app in Okta.
- Optionally, they turn on Require SSO, which covers every organization on the account: people with an email on your domain then sign in only with SSO.
SSO and rules are set up in BloomText, not through the API. There are no /v1 endpoints for SSO settings, rules or the directory.
What Directory Sync does
Directory Sync reads the people assigned to BloomText in Okta, with their email, name, department, office, title and groups, and applies the account’s rules:
- A rule is one Okta group, or up to three attributes (department, office and title) that must all match. It gives a person an organization, the Admin or User role, and teams in that organization. Every matching rule applies; within one organization the higher role wins and the teams add up.
- The last rule catches everyone no other rule matches and puts them in an organization you choose. Who reaches BloomText at all is decided by who is assigned to the app in Okta.
- Rules never make someone an Owner or give them the IT role. Those are set only on the Account page in BloomText.
- Before saving, an Owner or IT person sees a preview of who will be added, taken over, removed or skipped, and confirms removals a second time. Test a person shows where one person would land and which conditions match.
Changes in Okta usually reach BloomText within about five minutes. When someone is deactivated, suspended or deleted in Okta, BloomText removes every membership they have on the account, whoever made it, removes any Owner or IT role, withdraws pending join requests and signs them out on every device. Their BloomText user is kept.
People are matched to their BloomText user by their Okta email. Someone who signs in with SSO before a rule gives them a place becomes a join request to the account’s default organization, labelled via SSO.
With the members API
Directory Sync and the members API can both manage people on one account, but not the same membership:
| Directory Sync | Members API | |
|---|---|---|
| Source of truth | Okta | Your HR or other system |
managed_by on the memberships it makes | okta | api |
| Changing the other’s memberships | Takes over admin- and API-made memberships that a rule matches, when an Owner or IT person saves the rule | Answers 409 managed_by_identity_provider |
| Leavers | Deactivate them in Okta | DELETE /members/{memberId} |
The account’s Allow Admins to invite people outside Okta switch stops organization Admins in BloomText from inviting people Okta doesn’t manage. It doesn’t apply to API keys.
Choose per person: use Directory Sync when Okta is where your staff live, and the members API for people outside Okta, such as contractors, or when your HR system is the source. Membership changes from both show in GET /member-events as Okta directory or API key: <name>.
Sign-in security with SSO
- Okta’s sign-in is the only extra check: BloomText doesn’t text a code to people who sign in with SSO, so require MFA in the BloomText app’s sign-on policy in Okta.
- Quick-login PINs are off for SSO sign-ins.
- What BloomText sends to WorkOS is limited to your default organization’s name, a sign-in email hint and WorkOS IDs; what comes back is each person’s name, email, department, office, title and groups. No patient information is shared.
Related
- Manage members: the API for staff and teams.
- Okta setup guide for IT , Set up single sign-on , Sign in with SSO in the admin help.
- Security and BAA.