This article covers what site admins should check when a student, parent, or staff member reports being unable to log in, including how to find where that user's password is stored and when the issue needs Finalsite Support.
💡 Quick answers
- What should be checked first? Where the user's password is stored. Go to Constituent Manager, then Settings, Constituent Roles, select the role, and check the Authorization field on the General Settings tab. Everything else depends on that answer.
- Why does that matter before anything else? Because it decides who can help. If the role authenticates against an integrated database or an identity provider, no Finalsite password reset will work, and the fix sits in the other system.
- What does it mean when a user is sent back to the login page after signing in? The credentials were accepted but the session did not complete. This is most often a duplicate or mismatched constituent record rather than a password problem.
- A family says the reset email never arrived. What now? Confirm the primary email address on the profile, then treat it as a mail delivery issue. School and district mail servers filtering the message is the most common cause.
- Can a password be reset on a user's behalf? Only for roles authenticated within Finalsite, and only when self-updating of passwords is enabled for that role.
- When should this go to Finalsite Support? After confirming the authorization source, that the profile exists once with a correct unique primary email, and that the user is signing in at the right address. Cases affecting a whole role or the whole site should go straight to Support.
In this article
- Step 1: Determine where the password is stored
- Step 2: Confirm the profile exists once, with the right email
- Step 3: Match the symptom to the cause
- Step 4: For Finalsite-authenticated roles, enable and use self-reset
- Step 5: For integrated and identity provider roles, redirect the request
- Step 6: Recognize when one report is really many
Step 1: Determine where the password is stored
This is the first step for every report, because it determines which of the paths below applies and who is able to resolve the issue.
Go to Constituent Manager, then Settings, then Constituent Roles. Choose the reporting user's role and open the General Settings tab. The Authorization field at the bottom of the window names the source.
- Finalsite. Passwords live in Finalsite, and a reset through the login page can resolve a forgotten password. Continue to step 2.
- An integrated database or identity provider. Passwords live in the other system. A Finalsite reset cannot help, no matter how many times it is sent. Continue to step 2, then see step 5.
- Users in more than one role. A person who is both staff and parent may have passwords in different systems. Check every role that person holds.
Full detail on authorization sources is in Help your users reset their own passwords.
Step 2: Confirm the profile exists once, with the right email
Look the person up in Constituent Manager and confirm three things:
- Only one profile exists for that person. Two profiles produce an ambiguous match, and sign-in can resolve to the wrong one or to neither.
- The primary email address is correct and unique. Reset emails go to whichever address is marked Primary. Where an address is shared across profiles, the reset email will contain links for every account using it.
- The profile is current. A record left over from a previous year or a previous import competes with the active one.
A single unique primary email address per constituent is the most effective way to prevent record mismatching. To resolve duplicates, including how to tell a manually created profile from a synced one and when to merge rather than delete, see Troubleshoot duplicate profiles in Constituent Manager.
⚠️ Important Note
Where a duplicate originates in a student information system, deleting the profile in Finalsite will not hold. The sync recreates it within 24 to 72 hours. The duplicate has to be resolved in the source system.
Step 3: Match the symptom to the cause
Asking what appears on screen narrows the cause quickly, and the four common symptoms lead to different places.
| What the user reports | Most likely cause | Where to go |
|---|---|---|
| Sent back to the login page after signing in | Duplicate or mismatched profile; less often a redirect rule or role configuration | Step 2, then Troubleshoot: Login loops back to the sign-in page |
| An error on the login screen, never leaving it | Wrong credentials, or the account is in a different role than expected | Step 1, then step 4 |
| The reset email never arrived | Mail filtering at the school or district level, or a wrong primary email address | Step 2, then step 4 |
| No password field, or an unexpected sign-in button | The role authenticates through another system, so no Finalsite password applies | Step 5 |
Step 4: For Finalsite-authenticated roles, enable and use self-reset
Self-service password reset is enabled per role, not site-wide. In Constituent Manager, go to Settings, then Constituent Roles, choose the role, open the General Settings tab, and select Enable self-updating of passwords. Repeat for every role authorized within Finalsite.
Once enabled, users can reset their own passwords from the login page. Confirm that the login page displays the Forgot username or password link, and consider adding instructions there for users whose roles authenticate elsewhere.
Where the reset email does not arrive, the cause is almost always the receiving mail server rather than the account. Ask the district IT team to allow-list Finalsite's sending addresses; see Whitelist Messages server IP addresses. This fixes it for everyone at the organization at once, rather than one user at a time.
Step 5: For integrated and identity provider roles, redirect the request
Users whose passwords live in an integrated database or with an identity provider cannot use Finalsite's password reset tool at all. Sending one repeatedly will not help and makes the real cause harder to see.
- Integrated database users. Direct the request to the password reset feature in the source system.
- Google, Microsoft, SAML, ADFS, or Azure users. Direct the request to the district IT team, who manage those credentials.
- LDAP users. The domain password applies, so the request belongs with IT as well.
Adding a note on the login page explaining where each group should go prevents these requests from arriving at all.
Step 6: Recognize when one report is really many
Fixing a single profile resolves that person's access and leaves the cause running. Treat a report as systemic, rather than individual, when any of the following is true:
- Several users in the same role report the same symptom within a short period.
- The same fault appears on multiple profiles, such as a wrong email domain or a missing identifier.
- Reports began soon after a data import, a sign-in configuration change, or a change made by the district IT team.
- No user in a particular role can sign in.
In these cases the source is usually the import, the account creation process, or the sign-in configuration. See Request early migration to the connected SSO experience for the user data standards that prevent most of them.
Contact Finalsite Support
Go straight to Support when a whole role or the whole site is affected, when an admin account is locked out with no other admin available, or when the steps above have been completed without resolution. Submit a request and include:
- The authorization source found in step 1, and the role involved.
- The username or email of at least one affected user, and one user who can sign in normally.
- The exact address where sign-in was attempted, and what appears on screen.
- How many users are affected, and when the reports started.
- Any change made near that time, on either the Finalsite side or the district side.
⚠️ Important Note
For security, Finalsite Support verifies identity before making manual account changes or password updates. Where the underlying cause is mail delivery or user data, resolving it locally is faster than requesting account-by-account overrides.
Comments
Please Sign in to leave a comment if you don't see the comment box below.