Sign in to Supportbench with Microsoft as an agent or customer

Microsoft sign-in can let an agent or customer use an approved Microsoft identity when entering Supportbench. It does not automatically create access to every Supportbench account or customer record. The correct result is a sign-in to the intended agent or Contact identity, followed by the normal permissions for that person. This guide explains the native Microsoft button; customer-portal SAML is a separate setup.

Start with the correct sign-in context  ·  Sign in as an agent  ·  Understand the agent identity prerequisites  ·  Sign in as a customer  ·  Understand consent and administrator approval  ·  Example: one customer company with several support contacts  ·  Check the complete result  ·  Troubleshoot by the last successful step

Start with the correct sign-in context

An agent session and a customer-portal session serve different purposes. A person can be an agent in one context and a customer Contact in another; signing in to one does not establish the other. Confirm the URL and intended role before troubleshooting a password or permission error.

Sign in as an agent

1. Open the agent sign-in URL supplied by your organization. Confirm the expected Supportbench account before entering any credentials.
2. Choose Microsoft. Depending on the sign-in screen, first open the provider option labeled Microsoft, Google, or organization SSO.
3. At Microsoft, select the work identity your administrator connected to this Supportbench agent. Complete the required Microsoft authentication and any applicable consent process.
4. Return to Supportbench and complete Verify it’s you if its two-factor policy requests an additional check. Successful Microsoft authentication does not skip every Supportbench account check.
5. Confirm the displayed agent and account in the workspace before opening customer records. Check that a known authorized case or work view is available.
6. If you reach the wrong identity or account, stop and ask the administrator to verify the binding. Do not create another agent or repeatedly enroll different addresses to make a login succeed.

The native provider must already be configured with the required Microsoft tenant/application values and callback or broker setup. A disabled provider can display Unavailable sign-in providers are not connected yet. That is a configuration issue, not proof that your password is wrong.

Understand the agent identity prerequisites

Current agent admission requires one verified active Microsoft-to-agent binding. The signed email must match the agent’s primary or secondary username, and the configured Microsoft tenant is validated. A matching email address by itself is not sufficient to grant agent access; duplicate bindings, mismatched email or the wrong tenant can prevent sign-in.

Some existing enrollment/compatibility paths can identify a unique existing agent by email and request explicit browser/mailbox confirmation. This does not mean Microsoft authentication automatically creates a new Supportbench agent. Follow the actual confirmation flow presented for your account; do not construct old callback or enrollment URLs as a manual workaround.

For an onboarding checklist, the administrator should verify the intended existing agent, active state, role/division access and correct verified Microsoft identity. Complete a real sign-in and an authorized record check before declaring onboarding finished. A Microsoft consent screen closing successfully is only one stage.

Sign in as a customer

1. Open the customer portal provided by the organization supporting you. Do not substitute the agent workspace URL.
2. Choose the available Microsoft sign-in option and select the Microsoft identity associated with your customer account.
3. Complete Microsoft authentication and any required consent. The portal then resolves the corresponding Contact or starts the permitted customer identity-linking process.
4. If Supportbench sends a verification email for a new or recovered link, open it and complete Confirm Microsoft sign-in → Confirm sign-in on the original portal. Merely opening the email link is not the final confirmation action.
5. Return to the intended portal and verify your displayed identity and available requests/knowledge.
6. If the visible customer history is wrong or missing, contact the support team with the portal URL and non-secret error/context. Microsoft authentication does not give you every Contact’s or Company’s cases.

A saved Microsoft tenant/object identity can identify an existing customer login. Where permitted, a new Contact can be provisioned from validated email/profile information. Inactive Contacts, disabled portal access and conflicting credential ownership still prevent admission. Existing login links remain intact while a new confirmation is pending.

Understand consent and administrator approval

Microsoft consent governs the permissions an application requests. Depending on the organization’s policies and requested permissions, the user may be able to consent or an administrator may need to review the request. See Microsoft’s user and administrator consent guidance.

In Supportbench, consent does not replace the provider configuration, correct agent/customer identity, active state or record permissions. Do not tell colleagues that one administrator clicking the Microsoft button completes the entire integration or enrolls everyone automatically. If Microsoft requests administrator approval, use the organization’s approved review process; do not weaken that policy to bypass the request.

This guide does not assert that every personal Microsoft account is accepted, that no password exists elsewhere on the Supportbench account, or that every Entra Conditional Access setting is automatically applied to every Supportbench sign-in route. Verify the actual provider configuration and the organization’s intended authentication policy.

Example: one customer company with several support contacts

A software vendor supports a customer’s IT administrator, finance contact and operations manager. Microsoft can authenticate each person, but the support portal must still associate each one with the right Contact and apply their customer role and Company relationships. The operations manager should not gain broader request history merely because they use the same Microsoft tenant as the administrator.

During rollout, test the intended contacts and permitted history separately from an agent login. Record which portal each person uses and who resolves customer-account mismatches. For a new employee joining the support team as an agent, establish the verified agent binding and role first; do not reuse a customer confirmation as a substitute for agent onboarding.

Check the complete result

• The browser returned to the expected Supportbench account or portal.
• The displayed identity is the intended agent or customer Contact.
• Required Supportbench confirmation and two-factor steps completed.
• A representative permitted record or task is available.
• Customer and role restrictions remain correct; access was not broadened merely to pass a sign-in test.
• The administrator knows which Microsoft tenant/application/binding owns the connection and how to handle account changes.

Troubleshoot by the last successful step

When requesting help, never send your password, token, verification code, complete callback URL or private customer content in a public article comment. Supply the minimum non-secret context through the approved support channel.

Continue learning

• Configure customer-portal SAML separately
• Connect an Okta SAML portal application
• Complete two-factor authentication
• Understand customer Company and Contact relationships