Front Login Guide & Troubleshooting (SSO, Can't Log In, Mobile)

First, know how you actually sign in

Front offers four sign-in methods, and the right fix depends entirely on which one your account uses. Per Front's guide to ways to create and sign into your account, those are: Google OAuth, Microsoft / Office 365 OAuth, a Front email and password, and single sign-on (SSO). Google and Microsoft OAuth reuse your existing Google or Microsoft account; email/password is a credential you set specifically for Front; and SSO is, in Front's words, "a sign-in method set up by the company to standardize the login for all tools the company uses" — configured by your IT admin, not by you.

That distinction is the whole game. A password reset that works for one method does nothing for another, and an SSO account has no Front password to reset at all.

Symptom → likely cause

1. You're using the wrong sign-in method

The single most common cause. Someone tries their email and a password on the Front login screen, gets rejected, and assumes the account is broken — when in fact the account was created with Google or Microsoft OAuth and has no Front-native password. The reverse also happens: an account made with email/password won't respond to the "Sign in with Google" button unless that Google identity matches.

Fix: On the sign-in page, notice which control you're using. If your organization runs on Google Workspace or Microsoft 365, try Sign in with Google or Sign in with Office 365 first rather than typing a password. If you genuinely set a Front password, use the email/password fields. When in doubt, ask whoever invited you to Front which method your seat was set up with — for a shared inbox, that's usually the workspace admin.

2. You need a password reset — for the right identity

If you use a Front email and password and it's genuinely wrong, the reset is simple. Per Front's sign-in documentation, click Forgot password? on the login screen, enter your associated email, and Front sends a reset message.

The catch is that this only works for Front-native passwords. Front is explicit about the other cases:

• Google or Microsoft OAuth: "Reset your password directly in Google or Microsoft." Front never held that password, so its reset link won't help — fix it at the source.
• SSO: "Reset your password directly in your SSO provider, or contact your company's IT team." Your credential lives in Okta, Entra ID, Google, or whatever identity provider your company uses — not in Front.

Fix: Match the reset to the identity. Resetting a Google password when your account is really SSO (or vice-versa) is the quiet time-sink here.

3. iPhone: "You can't get there from here… use Microsoft Edge"

A specific, well-documented mobile bug. On the Front iOS app, teammates who sign in with Microsoft Outlook / Office 365 SSO can hit an error immediately after authenticating. As reported on Front's community, the exact message is: "You can't get there from here. You must use Microsoft Edge to access this resource." Per the community thread on this issue, it's a mobile-app problem — the Front Desktop App is unaffected.

The Edge demand comes from a Microsoft Conditional Access policy that restricts the resource to a specific browser; the mobile app's in-app browser trips it.

Fix: You have two honest options, and neither is "install Edge and hope":

1. Sign in with email/password on the mobile app instead of the Outlook SSO button — the community's working workaround, which sidesteps the Conditional Access redirect entirely.
2. Escalate to your IT admin and Front support. In the thread, Front's own support specialist directed the reporter to the Support Team to investigate rather than chase the Edge message. If your company enforces Conditional Access, your admin may need to adjust the policy for the Front mobile app.

4. SSO fails, loops, or locks out the whole team

When SAML is misconfigured, nobody gets in. SSO issues are the highest-stakes ones because they can affect every teammate at once. Two facts from the Okta SAML setup guide for Front explain most of the pain:

• Enabling SAML affects all users. Per the guide, "enabling SAML will affect all users who use this application, which means that users will not be able to sign-in through their regular log-in page." Once SAML is on, the email/password page is no longer the door.
• There is no backup login URL. The guide states plainly that "Front does not provide backup log-in URL where users can sign-in using their normal username and password." So if the SAML config is wrong, there's no side entrance — the whole team is stuck until it's fixed.

The most common concrete misconfiguration is the Subdomain value: the Okta guide warns that entering the wrong subdomain in Okta's General tab "will prevent you from authenticating via SAML to Front."

On the flow itself: SP-initiated SAML starts at Front (you go to Front, Front bounces you to your IdP to authenticate, then back). IdP-initiated SAML starts at your identity provider (you click the Front tile in Okta or your Google apps launcher, and the IdP hands you straight into Front). If SP-initiated login loops but the IdP tile works, the problem is usually on Front's SP settings or the ACS URL; if the IdP tile itself errors, it's on the IdP app.

Fix (admin-only): This is genuinely not a fix an individual agent can apply — it lives in your identity provider and in Front's company-level security settings. Have your IT admin re-verify the subdomain, the SAML certificate, and the ACS/sign-in URLs. And if a bad rollout has locked everyone out, the escape hatch is documented: email Front support at [email protected] to turn SAML off, per the same Okta guide.

5. The login page loads but won't let you in

Browser state, not credentials. If the sign-in page appears but hangs, rejects a known-good password, or spins after you click a button, the culprit is often a stale session, a cached SSO cookie, or a blocking extension.

Fix: Work through these in order:

1. Hard-refresh the page (Cmd/Ctrl + Shift + R).
2. Open Front in a private / incognito window — this bypasses cached cookies and disabled-cookie issues, and is the single fastest way to tell a browser problem from an account problem.
3. Disable extensions (ad-blockers, privacy tools, password managers auto-filling the wrong identity) and retry.
4. Try a different browser — the incognito and different-browser tests together isolate whether it's your session or Front.
5. Confirm the URL is your real Front workspace URL and not a stale bookmark to an old subdomain.

6. It's not you — Front might be down

Before you tear apart your own setup, rule out a platform outage. If multiple teammates can't sign in at the same moment and nothing changed on your end, the issue may be on Front's side, not yours.

Fix: Check Front's status before spending an hour on your own config — our guide to whether Front is down walks through the status page and the fastest ways to confirm an outage. If it's a platform incident, the only fix is to wait it out; if the status page is green, come back to steps 1–5.

Where an AI layer quietly reduces the login pain

Here's a pattern worth naming: a meaningful slice of login trouble isn't really about login. A customer emails "I can't sign in," an agent has to reach Front to triage it, and the whole loop assumes a human is at the keyboard for work that's often routine — password-reset guidance, "which method do I use," account lookups. The broader category of AI agents for customer service exists to take that routine tier off the queue.

Macha is one such layer, and the framing matters: it runs on top of the Front you already use through the live Macha–Front connector — it does not replace Front, your SSO, or your shared inboxes, and it isn't a Front alternative. When a customer writes in with a routine question, Macha's agent reads the actual conversation in your shared inbox, understands intent, and can look up real account or order state through a custom tool that turns your REST API into something the agent can call — then drafts or sends a grounded reply. Fewer of those conversations need a teammate to log in and handle them by hand. Macha's credits are consumed per AI action, never per resolution. It doesn't fix a broken SAML config — that's still your IT admin's job — but it does shrink the volume of human-in-the-loop work sitting behind your inbox in the first place. If you're still wiring up channels, connecting Gmail to Front is a good companion once your logins are stable.

FAQ

Why does Front reject my password even though it's correct? Most often because your account doesn't actually use a Front password — it was created with Google or Microsoft OAuth, or with SSO. Try the Sign in with Google / Sign in with Office 365 button instead of typing a password, and if you use SSO, sign in through your company's identity provider.

How do I reset my Front password? It depends on your sign-in method. For a Front email/password, click Forgot password? on the login screen and enter your email. For Google or Microsoft OAuth, reset the password in Google or Microsoft directly. For SSO, reset it in your identity provider or ask your IT team — Front never holds that credential.

Why does the Front iPhone app say "You must use Microsoft Edge"? It's a known mobile-app issue when signing in with Outlook / Office 365 SSO — a Microsoft Conditional Access policy restricts the resource to Edge. The Front Desktop App isn't affected. The reported workaround is to sign in with email/password on mobile instead; if your company enforces Conditional Access, your IT admin and Front support may need to adjust the policy.

Our whole team got locked out after turning on SSO — what happened? Enabling SAML affects all users and disables the regular email/password login page, and Front doesn't provide a backup login URL. A wrong Subdomain or certificate value in your identity provider can lock everyone out. Your admin should re-verify the SAML config; to disable SAML in an emergency, email Front support at [email protected].

What's the difference between SP-initiated and IdP-initiated SSO? SP-initiated login starts at Front, which redirects you to your identity provider to authenticate and back. IdP-initiated login starts at your provider — you click the Front tile in Okta or Google and are handed into Front. If the IdP tile works but starting at Front loops, the issue is usually in Front's SP/SAML settings.

Want fewer of your teammates' logins spent on routine tickets? Start a free trial of Macha and connect it to your Front shared inbox in minutes.