Rhythm recognizes three kinds of sign-in: a Console user, a Portal member, and a partner system using an API key. Each one proves its identity in a different way. Console and Portal sign-in, sign-up, and password reset are handled by Auth0, the identity platform Rhythm uses for credentials and those account flows. You may see an Auth0-hosted page during sign-in, sign-up, or password reset. Rhythm staff also use Auth0 behind the scenes to support your account, but you and your colleagues should not try to sign in from Auth0’s own website. Administrators should always use your organization’s Rhythm Console address. This article explains how Rhythm recognizes each kind of sign-in, why one email address can have more than one sign-in method, and why changing an email address on a profile does not change the address someone uses to sign in.
Console Users and Portal Members Are Different Populations
Console users and Portal members are separate accounts. Each has its own password, even when both use the same email address. A member’s Portal password does not open the Console, and a colleague’s Console password does not open the Portal. If someone can sign in to the Portal but not the Console with the same email address, that is expected. Use the Console’s password-reset link instead of assuming the Portal password should work there too. Because the accounts are separate, setting up or fixing one does not affect the other. Creating a Portal account for someone does not fix a Console sign-in problem, and the reverse is true too.
Multi-factor authentication follows the same split. Turning it on for Console users does not affect Portal members. Guidance for setting up MFA for one group does not carry over to the other, so treat them as two separate rollouts.
Console access is for your organization’s staff and volunteers, and your administrators manage it on console user records. Portal access is for your members and other visitors, and Security & Settings does not directly administer those accounts. If you need to block a specific person’s Portal sign-in entirely, rather than changing their contact status in your console, Rhythm Support must do that for you. A blocked sign-in shows that person a message when they try to use it. For Console sign-in details, including how Rhythm chooses which account to open, what a successful sign-in looks like, and what to do when sign-in loops back, see Sign In and Choose Your Account.
A Sign-In Is Not the Same as an Identity Record
When someone signs in with a password or through a provider your organization has configured, that sign-in proves they control a specific email address or account. By itself, it does not tell Rhythm which console user or contact they are. Rhythm makes that connection separately, and the process is different for staff and members.
For a console user, the connection is direct. An administrator creates the console user record, which includes the person’s identity fields, such as name, email, and phone, along with the roles and policies that control what they can do. This article cannot point to documentation for how that person first gets a way to sign in, such as a password, invitation, or another method. The console user form has defined fields for a sign-in name and password, but administrators and the person being created do not see those fields on screen. In practice, after sign-in details appear on the person’s record, an administrator can sometimes set a password, send a password-reset link, or verify the person’s email address from the contact’s Security tab. Until a sign-in identity exists, there is nothing to reset. After someone has a working sign-in, their password does not expire on a fixed schedule. They keep using the password they set until they change or reset it themselves.
For a Portal member, Rhythm connects the sign-in automatically by matching email addresses, as explained in How Your Portal Sign-In Connects to a Contact. The first time someone signs in to a Portal, Rhythm looks for an active contact record with the same email address and connects the sign-in to that contact. When more than one contact shares the address, Rhythm chooses among those matches. If no contact matches, or the person needs to connect with a different email address than the one on their contact record, see Set Up Your Account or Sign In. A newly created Portal account may not appear in your console at all until the person finishes that first sign-in.
After the first match, the sign-in identity and the contact record stay only loosely connected. The email address entered during sign-up, or supplied by a social provider, is its own piece of data and is not automatically written onto the contact record. The person’s initial first and last name usually come from what they entered during sign-up, or from the social provider they used, not from anything Rhythm controls. The contact record’s own email field is populated separately when the person completes a Rhythm form during account setup. Because of that, a contact can have a working sign-in while still showing a blank email field in your CRM, and a Portal login can stay linked to a contact even when that field is blank. If someone signs up with Google, their email may not fully sync to their CRM record until their second Portal sign-in. A similar short delay can happen the first time a new Auth0-backed account’s verified email needs to reach the console. Newer accounts automatically save an already-verified social sign-in email onto the contact record when the contact’s email field is blank. This applies going forward only, so older records with a blank email are not automatically repaired. A sign-in method that never supplies an email still requires the person to enter and save one on their profile. An older account-setup sequence checked email verification before linking the contact. A newer sequence links the contact first and checks verification afterward, which works better when someone arrives through an integration or single sign-on path instead of Rhythm’s own sign-up screen.
Verification works the same way: it belongs to the specific sign-in identity, not to the person in general. If someone signs in with a misspelled address or sets up a second sign-in with a different email, Rhythm treats that as a new, separate login that needs its own verification. That is true even if an earlier sign-in for that person was already verified. An incorrect email on the identity record itself can also mean the verification message never arrives. After verification succeeds, the identity system should associate that sign-in with the correct contact profile in your console.
flowchart TD
A[Someone signs in] --> B{Console or Portal?}
B -- Console --> C[Console user record\ncreated by an administrator]
B -- Portal --> D[Rhythm matches the sign-in\nemail to a contact record]
D --> E[Sign-in connected to that contact\nfrom then on]
An email address listed as a secondary or assistant contact on someone else’s record does not decide who can sign in with it or set up a Portal account for it. Sign-in is tied to the person’s own login identity, not to other places their email appears in your records. A shared or distribution-list mailbox creates the opposite risk. If more than one person signs in with that same address over time, the login identity can end up associated with the wrong contact record, and untangling it takes cleanup and help from Rhythm Support.
Changing the email address on a console user record or contact profile does not change the address that person uses to sign in. The profile email and the sign-in credential are separate details, updated in separate places, even though they usually show the same address. If someone needs to start signing in with a new email address, set up a new sign-in with that address and connect it to their existing record instead of editing the email field on the record they already have. Password resets use the email address tied to the actual sign-in, not the email shown on the profile. If a reset says it cannot find an account, the profile email and sign-in email may no longer match. Check which address the person actually uses before assuming the reset is broken. After someone’s sign-in email has changed or been unlinked from an old identity, using password reset against the correct, current sign-in is usually the way back in.
Neither the person nor an administrator can directly edit a sign-in username or email from the Portal, the console, or Rhythm’s back end, because authentication is hosted outside Rhythm. The only path to a new sign-in address is to create a new sign-in and connect it to the existing record. A Portal username follows the login account it was created with; merging duplicate contact or profile records does not transfer or reassign it. One person may also have more than one email address on file, and Rhythm’s Security records can show more than one email tied to a single sign-in identity. When you troubleshoot, confirm which specific address the person actually signs in with instead of assuming it is whichever address looks most current. Do this especially after a contact’s email was changed or two contacts were merged, because either action can leave a sign-in identity that still needs to be checked separately from the contact record. Login history or password-reset options may not be visible from every record that could hold them, so check every associated record rather than just the one you expect. When one person has more than one related contact profile, each profile can need its own distinct login connected to it. Using the wrong login can take someone to the wrong profile. When someone has more than one email-based login identity, Rhythm Support may need you to confirm which one should remain the sign-in before the other is removed, rather than creating yet another account to work around it.
When Your Sign-In Identity Doesn’t Match What’s in Rhythm
Rhythm’s identity system and your Rhythm records can drift out of sync in either direction. Someone can exist as a sign-in identity without any matching console user or contact record. A person can also have a console user or contact record without the sign-in most people would expect them to have. If a colleague or member cannot sign in, or account creation fails, and you cannot find a matching record in Rhythm, that does not mean no identity exists. Check with Rhythm Support, because a sign-in identity can exist even when nothing appears in your console or Security & Settings screens. A person can receive a welcome or account-setup email and still be unable to sign in if their sign-in identity was created without being connected to a console user or contact record.
A leftover or duplicate identity is a common reason a sign-in will not go through. This can happen when someone has a second identity record with a typo in the email domain, when an old identity from a previous email address survives a profile update or contact merge, or when an orphaned identity remains after the related contact or console user record was deleted. In each case, the fix is usually the same: Rhythm Support removes the incorrect or leftover identity so only the correct one remains, and the person signs in again or sets up a fresh account that reconnects to their existing record. Rhythm Support can also reset someone’s identity without deleting their underlying Rhythm record. The person then creates a new account and, during setup, is offered the chance to merge it with their existing record so their history is preserved. Administrators cannot remove a duplicate or stuck sign-in identity themselves, including a sign-up that is stuck because an identity already exists for that email. Contact Rhythm Support when you find one.
Deleting a contact or console user record does not automatically remove a separate sign-in identity tied to that person. If access needs to end completely, such as when someone changes employers or leaves your organization, plan to have the old sign-in identity removed as its own step. Do not assume it disappears with the record. For the same reason, do not repurpose a former employee’s old sign-in for someone new. Give each new person their own account from the start, because reusing one can leave the wrong sign-in history attached to the new person.
Merging duplicate contact records in your console does not merge sign-in identities. Login information tied to the record that was merged away does not carry over to the surviving record, and credentials and verification stay with whichever identity you kept. See What a Contact Merge Moves for the rest of what a merge does and does not carry over. A login can also keep resolving to the wrong contact. If a sign-in identity is still linked to an inactive contact, or to a different contact than the one you expect, Rhythm Support needs to delete that sign-in and have the person register again instead of trying to re-point the existing one.
If a sign-in fails, or an integration reports a login failure, even though the person says the password is correct, remember that the identity system has its own account state. That includes its own email verification, which Rhythm’s copy of the record does not always reflect. An identity-side issue can cause a login to fail even when the Rhythm record looks correct. Likewise, an identity-provider log showing successful authentication does not guarantee the Portal login completed afterward. A caching issue or similar problem can leave someone authenticated without actually reaching the Portal. Manual actions, such as verifying someone’s email, depend on that identity already existing. If the email is not found in the identity system at all, the person has not gone through account creation yet, and that must happen before verification is possible. Looking up someone’s login IP address depends on the same thing. Rhythm Support cannot provide it if no matching identity record exists for that person.
If an Account Already Exists
If an email address already has an account, setting up a new account with that same address does not create a second, separate account. Sign in instead. If you still cannot get in and a password reset does not help, make sure you are on the sign-in screen rather than the account setup screen. The two screens look similar, but they do different things. Using the wrong one is a common reason a simple sign-in issue does not resolve as expected.
Sometimes the message plainly says an account already exists and asks you to sign in. Other times, especially during sign-up through a social provider, you may see only a generic error, such as a message that something went wrong. That vague wording is intentional. For security reasons, Rhythm avoids confirming whether a specific email address already has an account or how it signs in. Either message can point to the same underlying cause: a duplicate or conflicting sign-in identity for that address, or simply being on the wrong screen. If a generic error continues after you confirm you are signing in rather than signing up, and you are comfortable gathering technical details, your browser’s developer console output can help Rhythm Support investigate.
If you still cannot get in after trying to sign in, log out and start over from a fresh browser session before trying a password reset. A stuck earlier attempt can sometimes cause a second try to fail in a confusing way. An email address that is fully tied to one existing sign-in identity may need to be removed from that identity before someone else can sign in with it. If you believe an old, unused address should be freed up for a different account, contact Rhythm Support rather than assuming it will resolve on its own.
More Than One Sign-In Method Can Share an Email Address
Rhythm supports password sign-in and, for some organizations, social sign-in through a provider such as Google. The same email address can have both a password sign-in and a social sign-in, or only one of them. A person can also have only a social sign-in, with no email-and-password login at all. Turning on social sign-in for your organization does not stop someone from also setting up an email-and-password sign-in with the same address, and the reverse is also true. Each method is a separate sign-in identity, even when more than one method leads to the same person’s record. Rhythm’s duplicate-account prevention only blocks creating a second identity with a sign-in method that already exists on that address. It does not stop someone from adding a different method, such as Google, to an email address that already has a password sign-in. Administrators can see which methods are linked to a person from the contact’s Security tab. If someone’s account-setup attempt fails because the contact already has portal credentials of some kind, such as a password sign-in, a social sign-in, or both, sign in with one of the existing methods or use password reset instead of trying to create a new account.
Because each method is separate, removing one sign-in method does not remove the others. If someone has both a password sign-in and a social sign-in for the same address, and one is removed, the other keeps working until it is removed separately. If you need to fully remove someone’s ability to sign in, check for more than one method instead of assuming one removal was enough. Rhythm Support can remove a specific person’s social sign-in without disabling that provider for everyone else on your Portal. When you ask, Support may first confirm which method the person wants to keep so the correct one is removed. A removal request should name the exact provider or method to remove, such as Google, LinkedIn, or email and password, rather than describing the problem generally.
Having more than one sign-in identity on the same email address is also a common cause of confusing sign-in failures, not just something to clean up afterward. Two profiles on one address, whether both social, both password, or one of each, can produce single sign-on confusion, an error stating a user with the same email already exists, or difficulty changing a password. This can happen even when the person tries a social sign-in from a different browser. Check whether the person’s other sign-in method still works before assuming the whole account is broken. When one method works, there is usually no need to also set up or repair the other. Removing a login method is not always the right fix. If the real cause is an external website’s single sign-on or logout configuration not clearing session state correctly between methods, or your organization runs its own single sign-on for the identity provider involved, deleting someone’s login method may not help. In that case, review the outside configuration, or ask your organization’s SSO administrator to check the identity-provider or authentication-profile setup, before removing anything in Rhythm. If a same-email error continues after a password reset, a social sign-in attempt, and switching browsers, the cause is usually a duplicate sign-in identity that needs to be removed on the back end, as described above, rather than a browser problem to keep troubleshooting.
When someone’s Portal access was originally created through a social provider, they generally need to keep using that same provider to sign back in. A Google-created account, for example, does not automatically work with a manually typed password. Someone who reports only an email-verification problem may still be able to get in with Google and should try that first before assuming the account is broken. The reverse also applies. If someone wants to move away from a social sign-in, or start using email-and-password instead of the social provider they used originally, they set up a new sign-in with the method they want and connect it to their existing contact record through the Portal’s account-setup flow. Completing account setup with the same email address as an existing social identity links the new sign-in to that same profile automatically, without creating a duplicate person. If an email address is reassigned to a different login, signing in there with a social provider may not work until the earlier identity linked to that provider on that address is removed. Using a traditional email-and-password sign-in with a new password on the reassigned address avoids that conflict. Before concluding a member has no way to reset a password, check their recent successful sign-ins as well as their configured method. A recent sign-in through email-and-password, for example, means that path is still available even if you first assumed the account was social-only.
Password reset, including any temporary password an administrator can set, only applies to an account that was originally created with a password-based sign-in. An account created only through a social provider such as Google has no Rhythm-managed password to reset or set. It cannot receive a Rhythm password-reset email, and administrators or Rhythm Support cannot test it through a normal password reset. If a member cannot get in and their only sign-in method is social, check their sign-in method before spending time on email deliverability. Direct them to reset their password with that provider instead. If your organization needs someone to have password-based access as an alternative, the person creates a separate email-and-password sign-in for the same address rather than converting the existing social identity.
Removing social sign-in has different effects depending on its scope. Removing one person’s linked social identity, whether to fix a problem or let them start fresh with an email-based account, does not affect anyone else. Afterward, that person goes through account setup again to create a new sign-in and reconnect it to their existing contact record. Turning off a social provider for your whole organization is a different, larger action. It stops both new sign-ups and existing sign-ins through that provider for everyone, including people who used it successfully before. Because Rhythm does not separate the two, disabling a provider such as Google also disables sign-up through that provider, not only sign-in. Anyone who relied only on that provider needs a plan to switch to email-and-password sign-in. They also need advance notice so they are not locked out. See what you can find out about who uses social sign-in today, later in this article, before you plan that communication.
If your organization is planning a single sign-on integration with an outside system, such as a learning platform, that is a separate technical conversation from anything covered here. Rhythm has existing SSO documentation that can be shared as a starting point for that planning conversation. Contact Rhythm for what that kind of integration needs from your side. Multiple sign-in methods on one address can also matter for an outside website integration. If a member’s account has both a password sign-in and an SSO-based sign-in, both should work as long as the outside site’s integration correctly clears and coordinates session state between them. A social identity created or reconnected through that kind of integration can also change which identity is active and cause a Portal access problem, such as a blank screen, until the sign-in is untangled and connected to the right identity again.
Social Sign-In: What’s Different by Provider
Rhythm’s social sign-in options are Google, LinkedIn, and Apple; Facebook is not offered. LinkedIn sign-in depends on your organization’s own configuration, so it can be available on one Portal and not yet set up on another. Each provider is turned on individually for your Portal. Enabling Google, for example, does not automatically enable LinkedIn or Apple. If one provider’s button is missing while another works, the likely cause is incomplete setup for that provider, not a display problem. Social sign-in also cannot be shown on only one of the sign-in and account-setup screens. It is either available on both or turned off on both.
A few provider-specific details are worth knowing before you troubleshoot a social sign-in problem as a general one:
- Apple. Apple lets a person share their real email address or use a private, randomly generated relay address instead. This choice belongs to Apple and to the person signing in. It is native to Apple’s sign-in and cannot be turned off by Auth0 or Rhythm, so an account created this way may have a relay address on file instead of the person’s everyday email. Setting up Apple sign-in for your organization also takes more effort than the other providers. Apple ties the configuration to one individual’s own Apple account, so that person has to complete setup and authenticate it from their own phone. The work cannot be delegated to someone else.
- Google. Signing up with Google does not require the usual email-verification step that a direct email-and-password sign-up does, because Google has already verified the address. On iOS, Google’s restrictions on embedded browsers can cause a sign-in attempt from inside an app’s built-in browser to fail with an unsupported-browser error. This is a Google-side restriction on the login method the app is using, not a Rhythm outage.
- LinkedIn. A LinkedIn connection has to be configured to request or map the person’s email address. Without that setting, LinkedIn sign-in can complete without ever supplying an email to Rhythm. If you turn that setting on after the fact, people who already tried to sign in with LinkedIn need to sign in again before Rhythm receives their email address. LinkedIn sign-ins have also been reported to still show as "Not Verified" on a contact’s Security tab even after successful verification, more often than with Google.
Disabling a social provider is an all-or-nothing, organization-wide change. It removes both sign-up and sign-in for that provider for everyone, including people who used it successfully before. Because Rhythm does not separate the two, disabling Google, for example, also disables Google sign-up, not only Google sign-in.
A social sign-in that fails often shows an error page hosted by the provider, not by Rhythm. A message about a redirect URI mismatch, invalid client, or blocked access usually points to the provider-side application registration not matching your Portal’s configuration, rather than a Rhythm outage. Keeping your Portal’s domain, your identity-provider connection settings, and each provider’s registered redirect address and client credentials aligned avoids most of these issues. Rhythm can help confirm the settings if you are not sure where a mismatch is. A person’s display name or other profile details for a social-login account come from that provider, not from Auth0 or Rhythm directly. A request to rename or correct that information usually has to be made with the provider, not with Rhythm Support.
Multi-Factor Authentication and Other Sign-In Checks
Enabling multi-factor authentication (MFA) for Console users is a coordinated change Rhythm makes for you, not a self-service setting. Work with Rhythm to schedule it, and let your staff know before the cutover date. As soon as MFA is turned on, Console users cannot complete sign-in until they enroll. MFA typically rolls out for existing console users in staged waves rather than everyone at once. Starting with a small, lower-risk group first is a reasonable way to confirm it before expanding it, and MFA can only be applied to people who are already console users. After it is enabled, it applies across every account under your organization, not to one account in isolation. If a colleague was already signed in before enrollment was required, they may need to sign out and back in before the enrollment prompt appears.
Console MFA works with common authenticator apps, including Google Authenticator and Microsoft Authenticator. Your organization can choose the app it prefers before Rhythm turns MFA on. Setup goes through these Auth0-based TOTP options, or through Duo, rather than one required app. If your Console access is set up through Duo, this integration needs Duo’s Web SDK application type. An Auth API application, or an older Okta/Auth0-style application, does not work the same way. If your Console users already authenticate through an identity provider such as Azure AD/Entra, whether that provider’s own MFA enrollment is enough on its own, or a separate Rhythm-specific enrollment is also required, has not been settled as of this writing. Confirm the current expectation with Rhythm before you plan a rollout around it. Rhythm currently has no configurable grace period that delays MFA enforcement for a set number of days after it is turned on. If you want to soften the transition, you can add instructional text near the top of the sign-in page instead.
Phone-based MFA verification, by SMS or voice, depends on the person’s contact record already having a phone number on file. Without one, that option is not available to them. A phone-based MFA attempt can also return an error about exceeding the maximum number of messages allowed per hour, even on what looks like a first attempt that day. This has been reported to affect more than one enrolled person at a time, so do not assume it means the person made repeated attempts. Being signed in under the wrong linked identity can also affect MFA enrollment. If someone was signed in with a different account than the one they meant to use, signing out and back in with the intended email address can produce a fresh setup code and let their MFA app enroll successfully. If a Console user permanently loses access to their MFA method, and MFA is configured through your organization’s own external identity provider rather than through Rhythm directly, only that provider may be able to help recover it. Rhythm Support does not manage credentials it does not control.
CAPTCHA is not currently supported for Rhythm’s own user sign-in. Where a related anti-bot check does apply, such as on account registration, it can be turned on in one environment, such as your sandbox, without being turned on in your live account. A production rollout is often held back intentionally pending your confirmation and a planned cutover date. Console users are not intended to face the same anti-bot friction as Portal-facing sign-in traffic. That distinction is by design, to avoid unnecessary prompts for your own staff.
A Partner System Signs In Differently
A partner integration does not sign in as a person. It presents an API key, which is a credential your organization issues rather than a password someone types. Rhythm treats the request as coming from that key, not from a signed-in person. This kind of machine sign-in has no session, no "who am I signed in as" screen, and no password to reset. API Keys covers the full lifecycle of that credential, including creating it, disclosing its secret once, rotating it, and revoking it.
A different kind of integration lets your members sign in themselves through single sign-on, using a web SSO key instead of a person typing a Rhythm password. See API Keys for Partner Integrations for how that key is configured. When your integration reads the resulting identity information, the userinfo response uses the Rhythm contact ID as the system identifier for the person, not their name or email address. Additional profile data, including security policy information, is included only when your integration explicitly requests it. Ask for the securityProfiles scope if you need a person’s security policies in the payload. A decoded token may also include other Rhythm and identity claims, such as customer, account, contact number, contact name, email, email verification status, and a last-modified timestamp. The exact claims present can vary, so validate the actual token payload your integration receives instead of assuming every claim is always present. In particular, the Rhythm contact ID claim is present only after the underlying Auth0 user has been linked to a Rhythm contact record. Before that link exists, do not expect it. A sign-in reached through single sign-on has been reported to remain active for about 24 hours before the person needs to authenticate again. Treat that as an observed pattern, not a documented, guaranteed session length.
If a newly created Portal user is missing expected profile metadata, such as their contact name, some external integrations fall back to another field, such as the person’s email address. That can make the email display as the person’s name. If your integration behaves this way, check whether the expected name metadata is actually present before assuming the display-name logic is wrong on your end.
After a successful SSO sign-in, Security Policies can serve as a cross-application eligibility check for the person you just authenticated. Instead of calling several different application APIs to work out what someone qualifies for, an integration can call an endpoint that lists the security policies a contact qualifies for, or check a contact against one specific policy. A details endpoint used by Rhythm’s own SSO plugins also returns policy information with commonly requested membership fields, such as membership type, active-member status, and membership number, in a single call.
A Portal member’s own sign-in token only reaches endpoints meant for portal users. It cannot call console-only endpoints, such as endpoints for reviewing security permission profiles, and doing so returns an authorization error rather than the data. If your Portal-facing integration needs that kind of information, request it through a portal-facing endpoint instead. Along the same lines, confirm your integration’s Portal domain matches your account’s identity-provider address. A mismatch between the two can redirect people to an unexpected address and break sign-up or first-time sign-in.
If your integration passes identity data through single sign-on or an API and you see garbled accented characters, curly quotes, or certain dash characters, check that every system in the chain is handling UTF-8 correctly. A character-encoding mismatch anywhere along that chain, not only at Rhythm’s end, is a common cause.
Other Rhythm Products Sign In Separately
Rhythm Payments, used for merchant account boarding and payment processing administration, has its own sign-in. It is managed separately from your Console and Portal, and payments-portal users are administered outside the main console and portal you use every day. Password reset there requires the account’s username, not an email address. If you see an invalid username/password error after multiple reset attempts, check that you are entering the username rather than an email address or another identifier. That alone can cause the error even when the password itself is correct.
A sandbox’s custom domain does not automatically get its own copy of the identity system your live domain has. Pages that require sign-in, such as a pricing or registration page on a microsite, can fail to load on a sandbox custom domain for that reason, even when the domain’s root page loads fine. Making the specific page public, so it no longer requires sign-in, is a workaround if you run into this while testing in your sandbox.
Customizing the Sign-In Experience
The hosted sign-in and sign-up pages, the welcome and verification emails, and the account-setup screen all support some customization. They also have real limits that are worth knowing before you request a change.
Branding a logo on the login page usually needs two changes, not one: the visible branding setting and the image address referenced directly in the login page’s customization code. If a branding update seems only partly applied, especially when the logo itself did not change, check every place in the page template that references a logo address. An old address left in the template is a common cause. Changing someone’s photo inside their Rhythm profile does not update the photo or greeting shown on the hosted sign-in page, because that page pulls from the identity system, not from the Rhythm profile. You can use that same branding, such as the graphic at the top of the sign-in window, to help steer people toward the correct screen. For example, it can help when many people mistakenly try to sign in when they should set up an account instead.
Text on these pages has real formatting limits. In the sign-in box, specific words cannot be given bold or other inline formatting. Formatting applies only to the entire paragraph, not to selected words. If you need to emphasize just part of a message, either bold the whole paragraph or add a separate link pointing people to the right first-time sign-in destination. Some existing helper text on the account-setup and sign-in pages can be edited, but not every part of the page’s layout or wording is open to customization. Confirm requests for changes outside the existing text with Rhythm first. After any change to this hosted page, verify that the flow still works. Layout and sign-up problems, such as fields stretching oddly across the page or errors during account setup, have both happened after presentation-only edits and are easy to miss until someone tries the flow.
Which of the sign-in and account-setup screens appears first is controlled by an "Initial Screen" setting inside the login page’s code, not by a separate visible toggle. Removing that setting changes the default from account setup to sign-in. Footer legal links on the account-setup screen, such as a terms-of-service or privacy-policy link, can also be relabeled, pointed to a different page, or removed if you no longer need them there.
Verification and welcome emails for console users take the greeting name from the identity system’s user profile tied to your account, not from a Rhythm email template or the console user record. If that profile has a typo in the name, that typo appears in the greeting, and correcting the identity-side name fixes it. The account-verification email wording is also managed through the identity system rather than the Portal’s content tools, so a text change there usually needs to go through Rhythm Support instead of an edit you make yourself in your Portal content.
Troubleshooting Common Sign-In Problems
Before escalating a sign-in problem, try a few simple checks that resolve many cases. A Console sign-in that loops back to the sign-in page without an error is often fixed by clearing the browser’s cache and cookies and restarting the browser. An intermittent Console sign-in failure that follows an identity-provider callback error often points to stale cached sign-in state in that browser, especially if it works in an incognito or private window but not in a normal browser window. Clearing cookies and cache, or comparing a private window against a normal one, is useful as both a diagnostic and a possible fix. If the sign-in works only in a private window, that suggests a browser extension, cached cookie, or other browser-side state is the problem, not a Rhythm outage.
Impersonation, sometimes called "login as," is a separate authentication path from a person’s own direct sign-in. It can fail on its own even when direct sign-in works normally. Treat login failures, impersonation failures, and failures that only appear afterward while navigating as separate symptoms to isolate, not one combined problem. If impersonation fails for only one staff member while it works for everyone else, including a coworker who cannot reproduce it, that points to that one person’s identity, verification, or session state rather than a broader configuration problem. When someone appears to have signed in as the wrong person entirely, check which login credentials are attached to each record. Also review your account’s audit history for a prior merge or account-linking action that might explain the mismatch before assuming the current configuration is wrong.
An impersonation session logging out can show an attempt-related error message that does not appear when someone logs out of their own direct session. This is expected, does not mean multi-factor authentication failed, and does not mean anything is broken. Refreshing the page returns you to the sign-in screen. IP address whitelisting, where your organization uses it, applies to Console access, not to Portal impersonation. If someone can already reach the Console successfully, whitelisting is not what is blocking a separate Portal impersonation issue for them. Testing through impersonation, or through any staff or proxy session, can also behave differently from a real member’s direct session, because staff accounts often have elevated access a normal Portal member does not have. When you troubleshoot a permission-specific Portal problem, or verify a fix, log in directly as the affected person or as a real test account in the same organization instead of relying only on impersonation. Whether impersonation works at all can also depend on an eligibility requirement setting. If impersonation as a console user is not working during testing, confirm that setting is not restricting it before assuming the feature itself is broken. An intermittent Portal impersonation problem that affects only one machine, especially one involving a browser or network condition such as IPv6, is sometimes a local machine or network issue rather than an issue with your account’s configuration. Ask the affected person’s IT team to check local logs if the problem only ever happens on one computer. Portal impersonation can also occasionally show an identity-provider callback address mismatch error even when a member’s own direct sign-in works fine, because impersonation can use a different sign-in redirect path than a direct Portal sign-in.
Before you change any callback or redirect setting on Rhythm’s side for a Portal sign-in problem, confirm where the actual sign-in control is hosted. If the sign-in button lives on an external website rather than being fully hosted by Rhythm, that external site can control the redirect behavior, and the fix may belong there instead of in your Rhythm configuration.
Finally, remember that Rhythm records edits under whichever account is currently signed in, including when one person is using someone else’s active session. If an edit looks like it came from the wrong person, consider whether someone was signed into another person’s account or console session at the time before assuming the audit trail is wrong.
The Security Tab Shows History, Which Can Lag or Persist
A contact’s Security tab in your CRM shows login history, not a live, complete picture of someone’s current sign-in state. Several of its behaviors follow from that.
It can be blank even for someone who has signed in. Fields there typically do not start populating until a person’s second successful Portal sign-in, so a single login may show nothing at all. It also does not show whether a person used social sign-in or password sign-in. Rhythm can see that distinction on the back end, but there is no equivalent indicator shown to your administrators today. Google and LinkedIn sign-ins specifically do not appear in the login-activity report, so do not rely on that report to confirm whether someone has used a social sign-in method. A username shown with a provider prefix on an export simply labels which external identity provider that sign-in came through. It is not a separate Rhythm username. Occasionally, multiple usernames appear for one contact. This happens through a member’s own account setup or account-linking activity, not because your staff merged contact records in the console, so do not treat multiple usernames as evidence of a merge problem.
The Security tab is also not a reliable guide to whether verification actually happened. A known display issue can leave it showing an email as Not Verified even after the identity system confirms the email is verified. Reports have affected LinkedIn logins more than Google logins. If you select Verify Email on the contact’s Security tab, that action does verify the person in the identity system. If the identity system agrees the email is verified, treat the address as verified rather than repeating the action or assuming something failed. The displayed status in the console can simply be stale. When you need to be sure, checking the identity system’s record is more reliable than the console banner or displayed status. The same is true for a Portal member’s own account-verification emails, which are confirmed through the identity-provider side or the contact’s Security tab rather than through the console’s email-history view used for password-reset emails. A federated sign-in method, such as Google, may also not show as activity on the Security tab until the person signs in with that provider again. If it is not there yet, that alone is not proof the sign-in never happened.
History on the Security tab also tends to persist after the underlying sign-in is gone, so do not read continued visibility there as a sign that a change failed. Removing a social sign-in, deleting an Auth0 login or profile, or fixing an incorrect Auth0 login mapping all leave the earlier login entry, and often the associated email address, visible on the Security tab afterward. That tab keeps historical login methods and login history rather than clearing them as sign-ins change, and there is no way to remove that historical entry from the console side. The tab can show more than one login method for a contact, current or past, and any of them may or may not still have access. Review carefully rather than assuming every listed entry still works. Removing a Portal login frees the associated email address for someone else’s new Portal account, but the original email typically remains visible on the old contact’s Security tab as historical information. Login counts on a re-created account start over from the new account’s creation date rather than carrying over prior history. If a Portal login was not synced into Rhythm when someone first signed in, asking them to sign in again is a reasonable way to get that activity to populate the Security tab afterward.
If you are troubleshooting a case where your own systems seem to disagree about an email’s identity, check what the Security tab shows against the underlying identity system directly rather than relying on the console alone.
What You Can and Can’t Report on Sign-In Activity
Rhythm currently has no supported way to query, report on, or list Portal members by their sign-in method. You cannot pull a list of members who use only social sign-in, generate a report of users by login method, or query the Auth0 login email alongside your contact records from within Rhythm reporting. Portal login-count and last-login query fields only began being tracked starting December 21, 2023. Earlier login activity can still appear on a contact’s Security tab or in the identity system directly, but it will not show up in these query fields. That can make it look like someone has never signed in when they actually have. There is also no front-end way to identify which member records were created through social sign-in.
If you need a list like this, such as before turning off a social provider, ask Rhythm Support and engineering. They may be able to help as a last resort by pulling data from the back end. Even then, some records may not match cleanly between Rhythm and the identity system, so treat the result as a best effort rather than a guaranteed complete list. Because you generally cannot identify social-sign-in users in advance, the safer approach before disabling social sign-in for your organization is to notify all members ahead of time. Ask anyone who has not already done so to create an email-and-password login, rather than trying to target only the people you believe are affected. Turning off social sign-in without advance notice can strand people who only ever had a sign-in through that provider, so plan for communication and, if needed, a migration or password-reset step well before you make the change.
Support and the Identity Platform Behind Sign-In
Rhythm’s identity platform, Auth0, has some things your administrators and Rhythm Support can both act on, and some things that stay with your organization or with the platform’s own security design.
Your administrators do not get direct access to the underlying identity provider for your Rhythm account or to its logs. Rhythm Support can review those logs on your behalf to help troubleshoot a sign-in problem. Rhythm Support can also test whether your Portal’s password-reset flow is sending email successfully. Deeper identity-system configuration is something your organization may need its own separate access to inspect or change, and Rhythm Support may not have that access either. Only Rhythm staff can delete an identity-provider sign-in profile. If one needs to be removed because it is duplicate, orphaned, or otherwise stuck, contact Rhythm Support rather than looking for a way to do it yourself.
When Portal authentication for your organization is handled through your own identity-provider setup, password resets for those sign-ins happen there, not through Rhythm. An administrator needs access to that setup to manage them, so do not expect the Portal’s Forgot Password flow to help in that situation. Separately, for security reasons, the identity platform’s password-reset flow deliberately returns the same generic response whether or not an account exists for the email entered, and regardless of how that account signs in. That response alone never confirms or denies whether an email has an account or how it authenticates. A verified email status can also take a little time to sync from the identity system back into Rhythm after the person verifies. If it looks unverified right after verification, wait briefly before assuming something is broken. There is no setting to automatically verify a person’s email in this scenario, because verification emails are sent by the identity platform, not by Rhythm directly. The account-verification email template is managed there as well, so request template wording changes through Rhythm Support rather than looking for a self-service editor. The sending IP address for these emails also depends on whichever email-delivery service is configured for the identity platform, which is often not an address Rhythm owns. If you need to allowlist a sending IP, you may need to work with that email provider to identify it, not with Rhythm.
An email address is the unique identifier for a sign-in, so the same email-based login normally cannot be attached to more than one unrelated Rhythm account unless those accounts share the same parent organization. If a person needs logins in more than one unrelated account, use a distinct email address for each one. A plus-addressed variant can work if your mail provider supports it, rather than trying to reuse one address everywhere.
If a Console user’s multi-factor authentication is configured through your organization’s own external identity provider rather than through Rhythm directly, recovering a lost MFA method may be something only that external provider can help with. Rhythm Support does not manage credentials or requirements it does not control.
Rebranding your organization, such as changing your name, does not require changing your underlying identity-provider configuration or losing your existing sign-in users. Rhythm can update the sign-in branding shown to your users, such as the email sender address and email templates, without changing your account’s core sign-in setup. Contact Rhythm Support to make these changes.