Admin consent guide

Last updated: May 4, 2026

If you tried to connect a work email account and saw a message like "Need admin approval" or "This app is blocked," you've hit your organization's admin consent policy. This page explains what's happening, what to do as a user, and what your IT admin actually needs to approve.

Why this happens

Microsoft 365 and Google Workspace let administrators control which third-party apps can access company email. This is a sensible security default — it stops random apps from siphoning company data without oversight. The flip side is that legitimate apps like InflowMail need explicit approval before users can connect.

You'll only see this if your account is on a managed business tenant. Personal accounts (@outlook.com, @hotmail.com, @gmail.com) don't have this restriction and connect freely.

Microsoft 365

If you're a regular user

You can't bypass the wall yourself — your tenant admin has to approve InflowMail once for the whole organization. The fastest path:

  1. Find out who your Microsoft 365 admin is. In small businesses this is usually the owner or whoever set up email.
  2. Forward them the email template you'll find on the connection blocked page after a failed attempt.
  3. Once they've approved (one click), retry connecting.

If you're a Microsoft 365 tenant admin

You can grant tenant-wide consent in two ways:

  • Direct admin consent URL — sign in once, click approve, done. Use this URL with your InflowMail client ID: https://login.microsoftonline.com/<your-tenant-id>/adminconsent?client_id=0e39696b-3cd9-46eb-b4e2-a7ddac0e59dd Replace <your-tenant-id> with your tenant ID or use common to be redirected to the right tenant after sign-in.
  • Azure portal → Microsoft Entra ID → Enterprise applications → search for "InflowMail" → Permissions → Grant admin consent for <your org>.

What InflowMail requests (delegated permissions)

  • Mail.Read — read messages in the signed-in user's mailbox
  • Mail.ReadWrite — move, label, and delete on the signed-in user's behalf
  • Mail.Send — send mail as the signed-in user (used only when the user composes a reply)
  • Calendars.Read — read the user's calendar (for sender-importance hints)
  • Tasks.ReadWrite — manage Microsoft To Do tasks the user creates from email
  • User.Read — read the user's basic profile (name and email)
  • offline_access — refresh tokens so the user doesn't have to re-authenticate every hour

These are delegated permissions — InflowMail can only act as the user who signed in, scoped to that user's mailbox. We don't request Mail.Read.All or any other tenant-wide application permissions.

Common error codes

Code Meaning
AADSTS65001 User or admin has not consented to this app. Tenant admin needs to approve.
AADSTS50105 User is not assigned to the application. Admin needs to assign the user (or set the app to "users can self-assign").
AADSTS90094 Admin approval required for one or more permissions.
consent_required Generic OIDC code for "user or admin must consent before continuing."

Google Workspace

If you're a regular user

If your Workspace blocks third-party apps, you'll see "This app is blocked" or a similar message instead of the consent screen. Same drill: ask your Workspace admin to add InflowMail as a Trusted app.

If you're a Google Workspace admin

  1. Open the Google Admin console.
  2. Go to Security → Access and data control → API controls → Manage Third-Party App Access.
  3. Click "Add app" → "OAuth App Name Or Client ID."
  4. Search for "InflowMail" or paste the OAuth client ID below.
  5. Choose "Trusted: Can access all Google services" (recommended) or "Limited" if you want to restrict to specific scopes.

What InflowMail requests

  • gmail.readonly — read mail and labels
  • gmail.modify — change labels and move/archive (does not include permanent delete)
  • tasks.readonly — read Google Tasks the user has created from email
  • calendar.readonly — read the user's calendar
  • openid profile email — basic identity

IMAP fallback

If your tenant blocks OAuth but still allows IMAP with an app password, you can connect via IMAP instead. This works most often with Gmail (which still supports app passwords for accounts with 2-step verification on). Microsoft 365 tenants generally disable IMAP, so this rarely works for Outlook.

For IT: security posture

  • Delegated permissions only. InflowMail never holds tenant-wide application permissions. Each user authenticates individually and grants access to their own mailbox.
  • OAuth tokens stored encrypted at rest. AES-256, per-organization isolation. Tokens are refreshed regularly via standard OAuth refresh flows.
  • No password storage. InflowMail never sees or stores user passwords. Even for IMAP fallback, app passwords are stored encrypted and can be rotated by the user at any time.
  • Audit logging. Every email body decrypt is logged with actor (user vs sync worker vs support) and surfaced to the user in their Data Access Log.
  • Revocable. Users (and admins) can revoke InflowMail's access at any time from the Microsoft 365 / Workspace admin consoles. Tokens are invalidated immediately on revoke.
  • More: full security documentation.

Still stuck?

If you've followed the steps above and your admin has approved InflowMail but you still can't connect, please open a support ticket and include the error code from the connection blocked page.