Check Google sign-in availability

Read the Google status for this account

Open Settings → Security → Google while signed in to the account you want to inspect. Connected means the account has a linked Google identity. Not connected describes the current account's stored methods, while Google sign-in is not enabled on this server describes environment configuration. These are different conditions. The status does not describe whether your market feeds are connected or whether a terminal subscription is active. Keep the account email visible in your investigation so a different Google address is not mistaken for the same OrderMap identity.

Choose the correct Google identity

When using the Google sign-in flow, choose the Google account that corresponds to the OrderMap identity you intend to access. A browser can already be signed in to several Google accounts and suggest a different one by default. Read the selected account rather than accepting the first familiar display name. Using another email can resolve to a different registration or waitlist flow with different resources. A matching-looking address also does not authorize silently linking a new Google subject to an existing OrderMap account.

Use the enabled sign-in flow

Return to the sign-in screen and choose the available Google action when the server offers it. Complete the provider prompts and follow the resulting OrderMap page. Existing linked identities and new registrations can have different next steps: a new identity may still need admission and required profile information. A successful provider selection does not by itself establish a completed OrderMap session. Wait until the workspace appears and verify Account, or follow the explicit verification, waiting or onboarding page that the application returns.

1. Inspect Google status in Security before signing out of a working session.
2. On sign-in, select the intended Google account and finish its prompts.
3. Check the resulting OrderMap identity or follow its registration instructions.

Understand additional email verification

Some Google registration flows provide an authoritative mailbox proof; others still require the emailed verification step. When OrderMap asks for that proof, complete it in the browser associated with the original enrollment. The extra verification is part of registration and does not mean entering your Google password into an OrderMap support form. A waiting state can follow successful identity verification because admission is controlled separately. A release message opens the registration opportunity, but fresh authentication proof can still be required if the original proof has expired.

Distinguish configuration and account problems

A server-not-enabled state means the current environment cannot offer Google sign-in. Use another already established method for the same account if one is available. A provider callback or origin error may instead concern the address from which the flow was started. Record the exact application origin and where the error appeared. Repeatedly trying different emails can create confusing comparisons between separate accounts, so keep the identity and browser stable while checking whether the failure is consistently associated with one step.

Confirm resources after access returns

After Google sign-in succeeds, inspect the account email and the expected saved workspace before concluding that access has been restored to the right identity. Layouts, watchlists, alerts, tickets and developer projects belong to accounts. A subscription on one address does not automatically appear on another. The profile form cannot repair identity ownership by changing a display name, and it does not expose a generic Google-linking control just because the status panel exists. Use the actual available account methods rather than assuming every account can add every method from this panel.

Give support safe diagnostic evidence

Report whether Google was Connected, Not connected or disabled on the server, the selected account address when relevant, browser, application origin and safe error wording. Say whether you were signing into an existing account or registering a new one, and whether the result was an error, waitlist page or onboarding page. Never send Google passwords, authorization codes, access tokens or browser session cookies. A configured client and a successful automated test do not prove a particular real browser or public callback has completed its production acceptance.