I’m having an issue connecting the Microsoft Outlook node credentials in n8n.
When I click “Connect now”, I get this message:
“Need Admin Approval”
We are using n8n license account
In Azure the user consent settings are configured as:
“Do not allow user consent”
“An administrator will be required for all apps and agent identities.”
Because of this, regular users cannot grant consent to the app registration.
My admin already approved the consent request, but the connection in n8n still does not work.
Has anyone experienced this before?
Do I need additional permissions, admin consent for specific API scopes, or different Azure App Registration settings for the Outlook/Microsoft node?
@dana_bida the “Need Admin Approval” in this setup happens because ur tenant has user-consent disabled (which u mentioned), so the OAuth flow blocks at the consent screen even for low-risk scopes. building on @kjooleng’s question, there’s actually two levels of admin consent to verify and both have to be in place:
first level — was the admin consent applied at the tenant level, not just the admin’s personal account? when ur admin clicks approval, they need to specifically check the “Consent on behalf of your organization” checkbox on the consent screen. without that, the grant applies to that single admin user only, not the whole org, so when regular users try to connect they hit the same block.
second level — did the admin grant ALL the scopes n8n’s Outlook node requests? typical set is offline_access, Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, MailboxSettings.Read, and some of these can require explicit per-scope admin consent depending on tenant config.
quickest way to force tenant-wide admin consent properly is to hit the admin consent URL directly, admin in browser:
ur tenant-id is in Azure portal → Entra ID → Overview. the n8n app client_id and callback URL depend on whether ur on n8n Cloud (uses n8n’s own Azure app — id visible in the credential modal in n8n) or self-hosted (uses ur own Azure app registration).
if u cant get tenant-wide consent through ur admin (some orgs lock this down really hard for any third-party app), the cleaner path is to register ur OWN Azure App Registration and switch to the “Microsoft OAuth2 API” credential type in n8n with custom ClientID/Secret. ur own app, ur tenant approves it once, and the admin keeps full control over scopes. takes about 10 min in Azure portal.
are u on n8n Cloud or self-hosted? changes which client_id u’d put in the consent URL.
One additional check: after your admin grants tenant-wide consent, go to Azure Portal → Entra ID → Enterprise Applications → find the n8n app → Permissions, and confirm it shows “Granted for [your org]” status on the required scopes. If some scopes still show “Not granted”, that’s the remaining blocker - admin needs to grant consent specifically for those missing scopes, not just approve the initial request.
This issue usually happens because of Azure permission settings, not n8n itself. Please check these things:
Admin consent is fully granted
Go to Azure → App registrations → API permissions
Make sure required permissions (Mail.Read, Mail.Send, User.Read, offline_access) are added, then click “Grant admin consent”.
Just approving the request is not enough.
Check Enterprise Application
Go to Entra ID → Enterprise Applications
Make sure:
Consent is shown as “Granted”
The app is not blocked for users
Redirect URL is correct
In App Registration → Authentication
Add exactly this URL from n8n:
Hi all,
Thanks for the quick response,
The problem was that I needed to add hidden scope permission that exists in the outlook microsoft built in credentials:
openid offline_access Contacts.Read Contacts.ReadWrite Calendars.Read Calendars.Read.Shared Calendars.ReadWrite Mail.ReadWrite Mail.ReadWrite.Shared Mail.Send Mail.Send.Shared MailboxSettings.Read
I was missing the Shared credentials; however I am not sure if I those credentials are secured for sharing
the .Shared scopes only let the workflow see items that have already been shared with the authenticated user via Outlook’s normal share/delegation — not other users’ private mail or calendars. ur not punching through anything Microsoft hasnt already approved. safe to leave on for typical use, only worth removing if u specifically dont want the workflow seeing shared mailboxes that ur user already sees in Outlook anyway.
