Request early migration to the connected SSO experience

Finalsite is rolling out the new connected single sign-on (SSO) experience to all clients in waves. If you'd like to move sooner rather than wait for your scheduled turn, you can request an expedited migration. This article explains what migrating involves, who's eligible, and the exact steps to request an early move, including the short questionnaire to complete and how to send it to Support.

In this article

• Step 1: Understand what migrating to connected SSO means
• Step 2: Decide if your site is eligible
• Step 3: Identify your sign-in method
• Step 4: Prepare user data
• Step 5: Request an early migration
• Step 6: Manage the process through your ticket

Step 1: Understand what migrating to connected SSO means

The connected SSO experience is a major upgrade to how you and your community log in across Finalsite products. It includes:

• enhanced security with multi-factor authentication (MFA)
• support for popular identity providers (IdPs) like Google and Microsoft
• a modern, consistent login page across all Finalsite products
• one sign-in that carries across the Finalsite products you use, so there's no need to log in again when switching between them

When we enable connected SSO for your site, you and your users are automatically logged out of your Finalsite products. The next time you return, you'll see the newly designed login page and can sign in as usual. Your existing accounts and passwords carry over; there's nothing your users need to recreate.

To keep disruption to a minimum, we enable SSO outside your business hours and verify that sign-in is working before we consider the migration complete.

To confirm which experience your site uses today, see Connected SSO and Legacy login: Which experience does my site use?.

Step 2: Decide if your site is eligible

The following products qualify for connected SSO migration today:

• Website / CMS (Composer)
• Finalsite Enrollment (EMS)
• Finalsite Mobile app
• Messages XR Enterprise (MXR-E)

If you use one of these products, you're eligible to request an early migration. If you're not sure which products apply to your account, note it on the questionnaire, and we'll confirm before scheduling.

Step 3: Identify your sign-in method

Eligibility tells us whether you can move; your current sign-in method tells us how quickly. This is the most important factor in setting expectations for your timeline.

• Email/username and password (standard login), Google, or Microsoft: These can usually be expedited ahead of the standard schedule. Nothing changes for your users: same accounts, same passwords.
• SAML (your own identity provider): We can begin right away, but enabling SSO requires a change on your identity provider, so timing depends partly on your IT team. Many schools choose to replace SAML with our fully supported standalone Microsoft or Google sign-in, which is simpler and removes the overhead of running your own SAML. We're happy to walk you through either option.
• LDAP: If your LDAP runs through Azure, moving to standard Microsoft is usually the cleanest path and lifts the LDAP maintenance burden. If you'd prefer to keep LDAP, our Identity team will configure it together with your IT team.

Beyond standard login, Google, Microsoft, SAML, and LDAP, we also support Apple and Facebook. If you're interested in one of these, let us know on the questionnaire, and we'll confirm the setup.

You'll also want to decide which sign-in methods to offer once SSO is enabled. If you use a custom identity provider (Google, Microsoft, SAML, or LDAP), consider whether you'd like to keep the standard email/password option as a backup, or move to your identity provider only. Fewer methods are generally simpler and more secure, and you can always add more later.

Step 4: Prepare user data

Most sign-in problems after switching to SSO stem from messy user records. Before you migrate, make sure that in Constituent Manager:

• each person has a single record (no duplicates for the same person)
• every record has a correct, unique email address
• inactive or outdated records have been cleaned up

Duplicate or outdated records are the top cause of "not authorized" and wrong-landing errors after the switch. If you're not confident your data is ready, note it on the questionnaire; we'd rather tidy this up first than rush and cause sign-in issues.

A couple of other things can affect timing: if your site isn't launched yet, or you're in the middle of another major change or have open mobile items, we may need to sequence the migration around those. Tell us your target date, and we'll be honest about what's realistic.

Step 5: Request an early migration

1. Complete the expedited request questionnaire. Open the SSO Expedited Request Form. It takes about five minutes and asks for:
   • the Finalsite products you use
   • how your users sign in today
   • the sign-in methods you'd like once SSO is enabled (and whether to keep email/password as a backup)
   • confirmation that your user data is ready
   • a few timing checks and your target timeframe
   • your school details and primary and technical/IT contacts
2. If you're unsure of any answer, leave it blank and note your question. Support will help you fill in the gaps. There are no wrong answers; the questionnaire simply helps us tell you whether we can start right away and what, if anything, to do first.
3. Contact Finalsite Support. Submit a request to Finalsite Support, attach or paste your completed questionnaire, and CC your Finalsite contact so everyone stays in the loop. Having your answers up front means we can move forward without a lot of back-and-forth.
4. Wait for confirmation. We'll review your answers and confirm eligibility, then reply through the same ticket with next steps and a timeline.

Step 6: Manage the process through your ticket

1. We review your questionnaire and confirm eligibility, usually within a couple of business days.
2. If everything's clear, we'll confirm your timeline through the open ticket. 
   • For standard-login, Google, and Microsoft clients, this can be an expedited slot ahead of the standard schedule.
   • For SAML/LDAP clients, we'll coordinate the identity-provider steps with your IT team first, especially if you'd like to keep your current configuration.
3. We enable SSO outside your business hours to avoid disruption, then verify sign-in is working so there's nothing you need to do on your side during the switch.
4. Once your SSO is enabled, you'll receive confirmation through the open ticket.