Connecting a mailbox fails in five distinguishable places, and the product names which one. Find your message here rather than starting the wizard again — a retry that repeats the same mistake costs the consent screen twice.
Stage 1 — the sign-in never starts
“Couldn’t start the Google sign-in flow” or “Couldn’t start the Microsoft sign-in flow” means the failure is ours or the browser’s, before the provider was reached. A blocked popup, or an OAuth client that is mis-configured on our side. Retrying immediately is reasonable; retrying five times is not.
Stage 2 — the consent screen
Sign-in failed, with:
Reason:
access_denied. Common causes: you cancelled the consent screen, or the OAuth client is mis-configured. Try again or contact support.
The far more common Gmail failure has no error at all. Google presents its two permissions as separate tick boxes, defaulted off, and the wizard warns you before it hands you over:
If you skip either checkbox, sending or receiving won’t work and you’ll have to re-do this flow.
A connection that completes and then never receives — or completes and cannot send — is almost always this. There is no message because nothing failed; you were granted exactly what you agreed to.
Stage 3 — naming the mailbox
Each shape has its own diagnostic, and each names the fix.
| Message | What it means |
|---|---|
| ”Your account doesn’t have Full Access on this shared mailbox.” | The Exchange grant is missing, or went to a different account than the one you signed in with |
”support@contoso.com doesn’t exist in your Microsoft 365 tenant.” | A typo, or a mailbox in another tenant from the one you signed into |
| ”Shared mailboxes only exist on Microsoft 365 (work/school) tenants…” | You signed in with a consumer Outlook.com / Hotmail / Live account |
| ”Couldn’t list your groups” | The Groups call failed, or you are not a member of any |
| ”The member mailbox does not have the group address configured as a ‘Send mail as’ alias.” | Google Group path: replies would leave as the member, not the group |
| ”No verified aliases found — add one in Gmail Settings” | The alias is not verified in Gmail yet |
Stage 4 — verification never comes back
The round trip sends a message from the mailbox to itself. When it does not return, the cause is infrastructure rather than anything you clicked, and the wizard says which side:
This usually means the Pub/Sub push subscription isn’t configured correctly — see the runbook or contact support.
For Outlook this usually means the Graph subscription isn’t reachable — confirm the public origin is correct and that the webhook validation handshake is responding.
Before concluding anything on the Microsoft side, wait:
Microsoft caches permission lookups for ~15 minutes — first send and first inbound may briefly act stale after the grant.
A first send that fails minutes after an admin granted the permission is very often that cache, and re-running setup during the window diagnoses nothing.
Stage 5 — it worked, and later stopped
The channel was disconnected.
Channel disconnected. Past messages remain visible above, but the AI can no longer reply and you can’t send from here. Re-connect the mailbox in Settings → Channels to resume.
Usually a revoked OAuth grant, a changed password, or an administrator removing the permission the connection borrows. On a Workspace shared inbox or an Exchange shared mailbox that is worth saying out loud: the connection runs on your access, so losing it takes the mailbox with it.
The connection is gone entirely.
This mailbox connection isn’t available anymore — it may have been deleted, or it didn’t finish setting up. Reconnecting the mailbox from the Channels page will start a fresh, clean setup.
Take that at face value — start again rather than trying to repair it.
Not on this page
If the mailbox connects fine and a specific message went unanswered, that is a different question with its own answers: why the AI didn’t reply.