Enterprise · FluxGate with Okta

Lifecycle

Every change to a person in Okta reaches FluxGate within seconds: joiner, profile change, mover, leaver and rehire, with no work in FluxGate.

5:50 videoBuilds on:People sign in

Before you start

Okta and FluxGate are connected as in the previous pages, with role sync mode SCIM.
Sign in to FluxGate as admin System admin and keep the Okta Admin Console in a second tab. Reload FluxGate pages to see changes; Okta sends them within a few seconds.

What each Okta event does

In Okta	FluxGate receives	Result in FluxGate	Audit log type
Add a person to an assigned group	A lookup by user name, then a create	Account created with the roles and teams of the group	`scim_user_created`
Change the profile	An update	Name or email updated	`scim_user_updated`
Move the person to another group	Group membership changes	Roles and teams follow the mappings	`scim_group_updated`
Deactivate the person	`active` set to false	Account disabled, sessions ended, history kept	`scim_user_deactivated`
Activate the person again	`active` set to true	The same account enabled, roles restored	`scim_user_reactivated`

Joiner

In Okta, open Directory, Groups, FluxGate Routing Developers, click Assign people, and add tom@brightwater.example.
In FluxGate, reload /settings/users. tom is listed with the SCIM badge.
Open tom. Assign Roles shows Requester and Assign Teams shows Routing, each with an SSO chip. tom can sign in now.

Profile change

In Okta, open Directory, People, tom, tab Profile. In Attributes, click Edit, change Last name, and click Save.
In FluxGate, reload tom's page. Last Name shows the new name. Name and email are locked and marked Managed by SCIM provisioning, because Okta owns them.

Mover

In Okta, add lena to FluxGate Routing Approvers and remove lena from FluxGate Routing Developers.
In FluxGate, open lena. Assign Roles shows Approver, and Requester is no longer ticked. The team stays Routing, because both groups map to it.

Leaver

In Okta, open tom, click More Actions, then Deactivate, and confirm.
If tom has FluxGate open, the next click returns to /login. The session ended when Okta deactivated the account. Sign in with Okta fails too, because Okta no longer signs tom in.
In FluxGate, open tom. Enabled is not ticked. Linked identities still lists okta. The account and every change tom made are kept.
In Audit Log, the entry scim_user_deactivated records the deactivation and the revoked sessions.

Rehire

In Okta, activate tom again and make sure tom is still in FluxGate Routing Developers.
In FluxGate, tom is Enabled again with Requester and Routing. The audit log has scim_user_reactivated. There is no second account.

Good to know

Okta never deletes a user in FluxGate. Removing a person from every assigned group also deactivates the FluxGate account; adding them back enables it again.
FluxGate refuses to deactivate the last enabled admin. A banner tells admins; make another admin first, then retry in Okta.
Okta sends a group rename with every membership change, so the audit log can show more scim_group_updated entries than the changes you made.
To follow one person, filter Audit Log by Type or by the person.

Next

Where to look when something does not sync: Troubleshooting.