Sign in to your customer portal: password, Microsoft, Google and recovery steps

Updated Wednesday, October 28, 2026 · Marcel Gravelle

Your customer portal is the website your support provider uses for self-service knowledge and customer support work. It may have that organization’s name, logo and domain rather than a Supportbench-branded sign-in page. Use the address supplied by your support provider and the sign-in methods shown there. A customer-portal login is separate from an agent’s Supportbench workspace account.

At a glance

For: customer-portal users and support teams helping customers sign in. Applies to: Supportbench Core.

Start here: The customer portal address supplied by the organization providing your support

Find the correct portal and account · Sign in with a portal username and password · Sign in with Microsoft when the portal offers it · Sign in with Google when the portal offers it · Use an organization’s SAML sign-in route when configured · Recover a forgotten password or missing confirmation · If you can sign in but cannot find a case or article · Example: two customer contacts, different support responsibilities

Find the correct portal and account

Open the portal link in a trusted support message, your organization’s approved resources or your support provider’s official website. If you do not have the address, ask the support provider for it rather than guessing a tenant name.
Check that the organization and domain are the ones you expect. A portal for another supplier or support account will not automatically recognize your identity.
Open the portal’s sign-in page. Branding and button labels can be customized, and the available methods depend on the portal template and configured provider connection.
Use the individual account intended for you. Do not borrow another contact’s credentials to see company cases.

You are trying to access…	Use…
Your organization’s customer support portal	The customer portal address and customer credential or supported provider method supplied by your support provider.
The support agent workspace	Your agent sign-in process. Customer provider sign-in does not create an agent or grant agent permissions.
A restricted article linked in an email	The intended customer portal and authorized customer identity. A link alone does not grant access.

After sign-in you may return to the page you requested or the portal’s landing page. There is no universal promise that every customer is sent to an agent-style dashboard.

Sign in with a portal username and password

On the intended portal’s sign-in page, enter the customer username you were given or registered. It is often an email address, but the stored portal credential username is not necessarily the Contact’s primary email.
Enter the password for that portal credential. Check keyboard layout and capitalization if the value is rejected; do not repeatedly guess a forgotten password.
Select Log in (the default button wording; your portal may customize it). If the portal requires an account-verification step, complete the legitimate message associated with your own registration.
Confirm the portal shows the intended signed-in identity, then open the case or article you need. If sign-in succeeds but the item is missing, use the access checks below.

The Contact must be active, permitted to use the portal and associated with a verified valid credential. An administrator may intentionally disable access even when you remember the correct password.

Sign in with Microsoft when the portal offers it

Select Sign In with Microsoft, or the portal’s equivalent Microsoft option. If no option is present, ask the support provider which sign-in method is supported for this portal.
Choose the intended Microsoft work or school account, or another account type the configured connection explicitly supports. If your browser offers a personal account with a similar address, do not assume it represents the same organization identity.
Complete the Microsoft sign-in and any verification your organization requires on the provider’s page.
If Supportbench asks you to verify the mailbox before linking the Microsoft identity, open the link in the message sent for this sign-in attempt. On the Confirm Microsoft sign-in page, select Confirm sign-in and return to the portal. Opening the email link alone does not complete the confirmation.
Verify the portal identity and the expected customer access. A successful Microsoft login may still require the Supportbench mailbox-linking step before customer access is granted.

Core uses the validated Microsoft identity and an existing binding when one is available. First linking or recovery can require email confirmation; it is not safe to assume any provider account with a similar displayed email can be substituted. For Microsoft’s own verification prompts, see Microsoft work or school sign-in verification. Provider guidance checked on 28 October 2026.

Sign in with Google when the portal offers it

Select Sign In with Google, or the portal’s equivalent Google option.
Choose the Google account intended for this customer relationship. If several accounts appear, check the full account address before continuing.
Review the provider’s sign-in or consent screen and complete the prompts for the trusted portal. Return to the customer portal when authentication finishes.
Confirm the signed-in identity and open an item you are authorized to use. If the portal rejects the account, ask the support provider to check the Contact and credential relationship.

A validated Google email can locate an eligible Contact or create an eligible customer Contact/portal credential through the configured flow. This does not create an agent account or grant access to every case belonging to the email’s domain. Conflicting credential ownership and inactive or access-disabled Contacts can prevent sign-in. See Google’s sign-in guidance for the provider screens.

Use an organization’s SAML sign-in route when configured

Some portals redirect you to an organization identity provider through SAML instead of showing the ordinary local form. Follow the organization’s sign-in route and complete its verification. If you are sent to the wrong organization or cannot return to the portal, give the support provider the portal address, time and the non-sensitive error text.

SAML, Microsoft and Google sign-in are not interchangeable names for one configuration switch. The support provider must configure a supported route, and customer record/access checks still apply after identity verification. Administrators should use the customer-portal SAML guide.

Recover a forgotten password or missing confirmation

Select Forgot Password? on the same portal where you normally sign in, or its customized password-recovery equivalent. Follow its instructions for the registered credential or mailbox; button wording can differ with portal customization.
Check the intended mailbox and its junk or quarantine handling. If you use a provider sign-in method, distinguish a provider password reset from a Supportbench portal password or mailbox-linking message.
Use the recovery or confirmation message associated with your current request. Do not forward a reset or sign-in confirmation link to someone else.
If the message does not arrive or the account remains unavailable, contact the support provider with your portal URL, intended username/account and approximate attempt time. They can review the Contact state and credential mapping.
After recovery, sign in again and check the intended identity. Do not create a duplicate Contact solely to work around an unresolved login problem.

Your support provider should not need you to disclose your password, one-time verification code or full reset link in a support conversation. Your organization’s IT team handles a Microsoft or Google account that cannot complete its own provider sign-in.

If you can sign in but cannot find a case or article

Situation	What to check
A colleague sees a case you cannot see	Your Contact/company relationship and explicit case visibility. Company membership does not necessarily mean every contact has the same scope.
A shared article link says unavailable	Whether the article is published for your audience, its restrictions and the intended portal.
Your name appears but company information is wrong	Ask support to verify the underlying Contact and company mapping; avoid creating more accounts as a workaround.
A different provider account signs in automatically	Choose the correct provider account through its supported account-selection/sign-out process, then retry the intended portal.
Access was removed after you changed roles or employer	Ask the authorized customer administrator or support provider to review entitlement. A working provider account does not override a disabled Contact.

Authentication answers who you are. Portal authorization determines what that identity may see or do. Give support a specific missing case ID or article link and explain what access you expected; do not ask a colleague to export restricted information just to bypass the problem.

Example: two customer contacts, different support responsibilities

A customer’s engineer uses the portal to work on technical cases, while its service manager reviews the permitted account context. Both may sign in with Microsoft, yet their case and knowledge access can differ according to the configured relationship and permissions. If the engineer cannot see an account-review item, the useful next step is to verify their intended access—not to reset a password that already works.

Was this article helpful?