Skip to content

Account linking & SSO migration

Enterprise

When SSO is enabled on a hub — or when enforcement is strengthened from Optional to Required — existing Fanzava participant accounts need to be linked to their SSO identities. Fanzava manages this transition through automatic email-based linking with a 30-day grace period, designed to migrate participants without locking anyone out unexpectedly.

Account linking is triggered the first time a participant signs in via SSO after the hub’s SSO configuration is enabled. Fanzava looks for an existing participant account matching the SSO identity’s email address. If one is found, the accounts are linked: the existing Fanzava participant record retains its tips, scores, group memberships, history, and badges, and is now associated with the SSO identity.

If no matching Fanzava account exists, a new participant account is created via just-in-time provisioning.

When SSO enforcement is set to Required, existing participants enter a 30-day grace period:

  • Both authentication paths work — participants can sign in via either their Fanzava password or your IdP
  • At each sign-in, participants who haven’t yet used SSO see a banner encouraging them to switch
  • Fanzava sends weekly emails to participants who haven’t completed an SSO sign-in, with instructions
  • Hub admins can view migration progress from Admin → Settings → Security → SSO → Migration progress

After the 30 days, the legacy password authentication path is disabled for participants who have not yet signed in via SSO. Their accounts are not deleted — they can complete the SSO migration at any time by signing in through your IdP, and their data is preserved.

The grace period length is configurable from 7 to 90 days on Enterprise plans.

If a participant’s Fanzava email and their IdP email differ — for example, they joined the hub with their personal email but their IdP uses their corporate email — the automatic match fails. Two options:

  • Manual linking — the participant updates their Fanzava profile email to match their IdP email before SSO sign-in, then the link forms automatically
  • Hub admin override — the hub admin manually links the accounts from Admin → Participants → [Participant] → Link to SSO identity, which is recorded in the audit log

If more than one Fanzava participant exists with the same email — which should be impossible per the account model but can occur after participant data imports — Fanzava refuses to link automatically. The hub admin is notified and must resolve the duplicate before SSO sign-in succeeds for that user.

If a hub permits both authentication methods (Enforcement: Optional), a participant can have a password and an SSO link active simultaneously. Either method authenticates them to the same participant record. Disabling SSO on the hub leaves the password active; switching to Required removes password access on next session expiry.

A participant who is in multiple Fanzava hubs (a contractor with two employers, say) maintains a separate participant record per hub. SSO configuration on one hub does not affect their authentication to other hubs. Each hub configures SSO independently.

For hubs enforcing SSO as Required, Fanzava strongly recommends maintaining one or two break-glass admin accounts that authenticate outside SSO — using Fanzava’s default email-and-MFA path. These accounts are essential for recovery if:

  • Your IdP becomes unavailable
  • Your SSO certificate expires unexpectedly
  • A misconfiguration locks out all SSO users

To set up break-glass accounts:

  1. Before enabling Required SSO enforcement, designate one or two senior admins
  2. Configure their accounts with default email-and-MFA authentication (not SSO)
  3. Store credentials in your organisation’s password manager with appropriate access controls
  4. Review break-glass access quarterly — confirm the designated admins still hold those roles
  5. Configure enforcement as Required with admin bypass rather than Required, so the break-glass accounts retain their non-SSO path

Break-glass accounts should not be used for routine work — they exist solely for recovery.

For hub admins preparing to enable SSO with Required enforcement:

  1. Configure SSO in test mode with one or two pilot users
  2. Verify the connection and complete pilot sign-ins
  3. Enable SSO with Optional enforcement — participants can use either method; SSO links form silently as people opt in
  4. Communicate to participants — email announcement, intranet post, hub announcement banner; explain the upcoming change and timing
  5. Set up break-glass admin accounts as above
  6. Switch enforcement to Required with admin bypass — the 30-day grace begins
  7. Monitor migration progress — daily during the grace period; aim for >80% before the grace ends
  8. Send reminder communications at days 14, 25, and 28
  9. Day 30 — the grace period ends; password authentication is disabled for non-migrated participants
  10. Provide support for stragglers — they can still complete SSO sign-in at any time
Was this page helpful?