The Azure app registration is the biggest hurdle for M365 in n8n: OAuth2 setup, scopes, and admin consent step by step.
Anyone who wants to connect Microsoft 365 to n8n, to process mails from Outlook, automate messages in Teams, or synchronize files in SharePoint, rarely hits a limit at the actual node. The Outlook, Teams, and SharePoint nodes in n8n are functionally well equipped and cover the common use cases. The real hurdle almost always lies one level deeper: with the Azure app registration and the OAuth2 setup, through which n8n gets access to a Microsoft 365 account in the first place. Anyone who goes through this step cleanly once has laid the foundation for all three services at the same time, because Outlook, Teams, and SharePoint technically run through the same Microsoft Graph connection in n8n. As of: July 2026.
This article shows which operations the three most important Microsoft 365 nodes offer, how the Azure app registration works step by step, and where most setups get stuck in practice.
The Microsoft Outlook Node covers six resources: calendar, contacts, drafts, appointments, folders, and messages including attachments. For messages, besides the usual operations like sending, moving, or replying, "Send and Wait for Response" is also available, with which a workflow pauses until someone gives approval by mail or provides feedback, for example as free text or via a custom-built form.
The Microsoft Teams Node brings operations for channels, channel messages, chat messages, and tasks, also including "Send and Wait for Response" for chat messages. This can be used, for example, to build approval workflows in which a digital worker sends a message to a Teams channel and waits for a response with buttons before the workflow continues.
The Microsoft SharePoint Node is more streamlined and covers files, list items, and lists: downloading, updating, or uploading files, creating, reading, updating, deleting, or merging list items via upsert, as well as retrieving individual or multiple lists.
All three nodes can work either with user-bound OAuth2 credentials or, from version 2 onward, with a Microsoft Entra service principal, meaning app-only access without a signed-in user. For government cloud tenants, the appropriate Microsoft Graph API base URL must also be selected in the credentials.
Before any of the three nodes works, n8n needs a registered application in Azure, or rather in the Microsoft Entra admin center. According to the n8n documentation on Microsoft credentials it works like this:
A detail from the Microsoft Learn documentation on app registration is worth knowing here: an application, once registered, cannot subsequently be moved to another tenant. Anyone working on a customer project who accidentally registers the app in their own tenant instead of the customer's tenant has to create the registration completely anew. So it is worth briefly checking which tenant you are currently signed in to before the first click on "New registration".
When choosing the account type, n8n and Microsoft Learn differ slightly in their recommendation: n8n recommends the broadest option with personal accounts for its own OAuth2 connection, while Microsoft Learn advises "Single tenant only" for most applications, meaning a restriction to your own tenant. For a purely internal company automation, where only employees of your own organization should get access, the narrower single-tenant option is usually the cleaner choice, even though n8n shows the open variant as the default example for compatibility reasons.
By far the most common error message on the first connection attempt does not concern the app registration itself, but the approval of the requested permissions. As soon as a Microsoft 365 account is managed by a company IT department via Microsoft Entra, the consent of the individual user is often not enough. According to the n8n documentation, either the setting "User can consent to apps accessing company data on their behalf" must be enabled for the tenant, or an administrator grants the consent separately.
In practice, according to Microsoft Learn, it works like this: after registration, the app initially only receives the basic permission User.Read. For all further scopes, such as Mail.ReadWrite or Calendars.ReadWrite, an administrator goes to the app registration under "API permissions", selects "Grant admin consent", and confirms the consent for the entire tenant. Only then does the status for the respective permission show "Granted". Anyone who skips this step often gets an error message during "Connect my account" in n8n stating that the administrator must consent, even though the client ID, client secret, and redirect URI are entered correctly. In practice, this means: before an M365 integration is tested at a customer's site, it is worth making a short call to their IT department so that admin consent is granted for the new app registration.
For access to a shared mailbox, the Outlook credential configuration in n8n offers the option "Use Shared Inbox" with an additional field for the user principal name or ID of the mailbox. For the generic Microsoft OAuth2 credential variant, n8n names Mail.ReadWrite, Mail.Send, Calendars.ReadWrite, and Contacts.ReadWrite as typical scopes.
SharePoint also needs a subdomain field in the credentials, for example "tenant123" from the URL tenant123.sharepoint.com. For permissions, n8n distinguishes between application permissions such as Sites.Read.All and Sites.ReadWrite.All, and delegated permissions such as SearchConfiguration.Read.All and SearchConfiguration.ReadWrite.All. If only the wrong category of permissions is granted, the node usually reports a 403 error, even though the app registration itself looks correct.
For pure app-to-app automations without a signed-in user, for example when a workflow permanently posts channel messages in the background, the Microsoft Entra service principal authentication is available from node version 2 onward. It works without an interactive login and is especially suited for server-to-server scenarios.
n8n supports two ways for the Microsoft OAuth2 credentials to authenticate against Azure. The client secret is the simpler way: a text value is generated under "Certificates & secrets" and expires after a set period, so it has to be renewed at some point. The certificate variant is more elaborate but longer-lasting. According to the n8n documentation, a suitable certificate can be generated with OpenSSL:
1openssl req -x509 -newkey rsa:2048 -nodes -keyout private-key.pem -out certificate.pem -days 365 -subj "/CN=n8n-microsoft-cert"Important here: it must be an RSA key. A common pitfall is using EC or Ed25519 keys, which Azure does not accept for this purpose. After generation, only the public certificate file is uploaded under "Certificates" in the app registration, while the private key and the certificate are entered into n8n. For most small and medium setups, a client secret with a reminder for timely renewal in the calendar is completely sufficient.
Once these basics are in place, the n8n automations from NordFlux can build on this, for example to build approval workflows via Outlook or Teams, in which digital workers prepare tasks and people only need to make the decision with a click. You retain control over every step, because every permission remains individually visible and can be revoked at any time.
In most cases, an administrator's consent to the requested permissions is missing. If the account is managed by a company IT department via Microsoft Entra, either the tenant setting for user consent must be enabled, or an administrator must explicitly grant admin consent under "API permissions" in the app registration.
Yes, technically one single app registration is enough for all three services, since they run through the same Microsoft Graph connection. In practice, it is still worth deliberately adding the required scopes per service, for example mail permissions for Outlook and sites permissions for SharePoint, instead of requesting all available permissions from the start.
According to Microsoft Learn, an already registered application cannot be moved to another tenant. In this case, the only option is to create the app registration anew in the correct tenant and then delete the old, incorrectly placed registration.
For most setups, a client secret is sufficient, it is set up faster but expires after a set period and has to be renewed. A certificate with an RSA key is more elaborate to set up but is a good choice if credentials should remain valid for as long as possible without manual intervention.
Yes. For Outlook, delegated mail and calendar scopes such as Mail.ReadWrite or Calendars.ReadWrite are usually sufficient. SharePoint additionally needs application permissions such as Sites.Read.All or Sites.ReadWrite.All, as well as partly delegated permissions for search configuration, depending on which operations the node should perform.
Founder of NordFlux. Spent four years automating processes at enterprise scale at Dräger, and now brings that depth to the mid-market — pragmatic and with full data sovereignty.
Certifications
Shopware 6 has no native n8n node. Here's how you connect orders, customers, and stock via the Admin API and HTTP Request Node.
Redirect URI, scopes, and especially admin consent on corporate accounts are where connecting Outlook, Teams, and SharePoint to n8n most often fails. NordFlux handles the setup and managed operation of your Microsoft 365 integration, including coordination with your IT administration. In our first conversation, we clarify which M365 services you want to connect.