Microsoft 365 with n8n: Outlook, Teams, SharePoint, and the Azure App Registration Hurdles

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.

Which Microsoft 365 nodes does n8n offer?

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.

Azure App Registration Step by Step

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:

• In the Microsoft Application Registration Portal select "Register an application" and give the app a name.
• Under "Supported account types" select the option "Accounts in any organizational directory ... and personal Microsoft accounts" so that the OAuth2 login works in n8n.
• Under "Web" as the platform, copy the OAuth callback URL from the n8n credential and enter it as the redirect URI.
• After registration, copy the Application (client) ID and paste it into n8n as the client ID.
• Under "Certificates & secrets" create a new client secret, copy the value, and enter it in n8n as the client secret.
• In n8n, click "Connect my account" and sign in with the Microsoft 365 account.

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.

The Most Common Hurdle: Admin Consent for Company Accounts

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.

Service-Specific Peculiarities

Outlook

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

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.

Teams

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.

Client Secret or Certificate: Which Variant Fits

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:

```

openssl 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.

Frequently Asked Questions

Why does n8n not connect to my Microsoft 365 account even though the client ID and secret are correct?

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.

Is one app registration enough for Outlook, Teams, and SharePoint at the same time?

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.

What do I do if I accidentally registered the app in the wrong tenant?

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.

Client secret or certificate, which is the better choice for n8n?

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.

Do I need different permissions for SharePoint than for Outlook?

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.