n8n an Microsoft 365 anbinden: Anmeldung über Entra ID und der Zugriff auf Outlook, Teams und SharePoint

n8n meldet sich an Microsoft 365 über eine Anwendung in Microsoft Entra ID an – je nach Baustein im Namen eines angemeldeten Nutzers oder, für unbeaufsichtigte Abläufe, als eigenständige Anwendung ganz ohne Nutzer. Für Ihr Unternehmen heißt das: Outlook, Teams und SharePoint bleiben unverändert; n8n bekommt einen benannten Zugang, dessen Reichweite Sie bis auf einzelne Postfächer herunterschneiden können.

Eine naheliegende Sorge: Ein zusätzliches Automatisierungswerkzeug bedeute einen Bruch mit dem eigenen Setup, ein Parallelsystem, eine zweite Wahrheit. Die Daten bleiben in Outlook, Teams und SharePoint führend. n8n kommt allerdings als zusätzliches System dazu und speichert die verarbeiteten Inhalte standardmäßig im Ausführungsprotokoll: Bei selbst betriebenem n8n sichert es laut Dokumentation die Daten erfolgreicher und fehlgeschlagener Ausführungen und löscht eine Ausführung, wenn sie älter als 336 Stunden (14 Tage) ist oder mehr als 10.000 Ausführungen gespeichert sind, dann die ältesten zuerst; Ausführungen mit Tags oder Bewertungen bleiben erhalten. Über EXECUTIONS_DATA_SAVE_ON_SUCCESS=none lässt sich das Speichern erfolgreicher Ausführungen abschalten (für fehlgeschlagene gibt es EXECUTIONS_DATA_SAVE_ON_ERROR), über EXECUTIONS_DATA_MAX_AGE die Frist verkürzen. Dieser Artikel zeigt, welche Microsoft-Dienste n8n von Haus aus erreicht, welche zwei Anmeldewege es gibt – und wie Sie den Zugriff auf genau den Ausschnitt begrenzen, den ein Workflow braucht.

Welche Microsoft-Dienste n8n von Haus aus erreicht

n8n bringt für die zentralen Microsoft-365-Dienste eigene Bausteine mit, in n8n „Nodes” genannt. Ein Node kapselt die Aufrufe an die Schnittstelle, sodass Sie im Workflow nur noch die Aktion auswählen. Der Stand laut offizieller n8n-Dokumentation am 27. September 2026; die neueste Version im n8n-Changelog ist zu diesem Zeitpunkt 2.41.0 vom 22. September:

Dienst	Node	Was der Node abdeckt
Outlook	Microsoft Outlook	Nachrichten (lesen, senden, antworten, verschieben, aktualisieren, löschen), Entwürfe, Anhänge, Ordner, Kalender, Termine, Kontakte
Teams	Microsoft Teams	Kanäle, Kanalnachrichten, Chat-Mitglieder, Chatnachrichten, Online-Besprechungen, Aufgaben (Chat-Mitglieder und Online-Besprechungen ab n8n 2.39.0, einzelne Operationen davon erst ab 2.40.0)
SharePoint	Microsoft SharePoint	Dateien hochladen, herunterladen und aktualisieren; Listen abrufen; Listenelemente anlegen, auslesen, aktualisieren und löschen
Excel-Arbeitsmappen in OneDrive	Microsoft Excel (OneDrive)	Tabellenzeilen anhängen, lesen und gezielt suchen; Arbeitsblätter anlegen und auslesen
Excel-Arbeitsmappen in SharePoint	Microsoft Excel (SharePoint)	eigener Node mit abweichendem Umfang: Arbeitsblätter auflisten, anlegen, leeren und löschen, Zeilen lesen, anhängen und aktualisieren; Tabellen auflisten, anlegen, in Bereiche umwandeln und löschen, Zeilen lesen, anhängen und gezielt suchen; Arbeitsmappen auflisten und löschen
OneDrive	Microsoft OneDrive	Dateien hochladen (bis 4 MB), herunterladen, abrufen, kopieren, umbenennen, suchen, teilen, löschen; Ordner anlegen, Inhalt auflisten, umbenennen, suchen, teilen, löschen
Benutzerverwaltung	Microsoft Entra ID	Benutzer und Gruppen anlegen, ändern, löschen; Mitgliedschaften setzen

Ein naheliegender erster Einsatz der Benutzerverwaltung ist das Anlegen eines neuen Kontos beim Onboarding – unser Beitrag dazu zeigt den Workflow davon ausgehend und ordnet daneben ein, welche Onboarding-Daten überhaupt in einen solchen Workflow gehören. Für den Austritt gilt dieselbe Lücke in umgekehrter Richtung: Die Node-Dokumentation listet für die Ressource User kein Feld zum Deaktivieren eines Kontos, sodass unser Beitrag zum Offboarding dafür auf genau den HTTP-Request-Weg aus dem vorigen Absatz zurückgreift.

Die Teams-Chatnachrichten aus der Tabelle oben stecken in derselben App-Only-Lücke: Mit einer Service-Principal-Zugangsberechtigung sind Chat, Chat Member und Chat Message laut Dokumentation nicht verfügbar, weil der Node Chatnachrichten nur im Namen einer angemeldeten Person sendet und liest. Das betrifft jeden Genehmigungs-Workflow, der auf Teams-Chat setzt – unser Beitrag zur Automatisierung von Urlaubsanträgen zeigt das am Beispiel der Genehmigung per Chat.

Drei Dinge sind daran für die Praxis wichtiger als die Liste selbst.

Erstens: Das sind Standardbausteine, keine Sonderanfertigungen – der Unterschied zwischen „geht grundsätzlich” und „geht ohne Entwicklungsaufwand”.

Zweitens: Was ein Node kann, ist nicht die Obergrenze dessen, was möglich ist. Dazu weiter unten.

Drittens, und das ist der Punkt, an dem Feature-Listen unbrauchbar werden: Die Nodes sind versioniert, und die Versionen unterscheiden sich in dem, was sie können – bis hin zu der Frage, welcher der beiden Anmeldewege pro Baustein überhaupt zur Verfügung steht. Prüfen Sie deshalb gegen die Node-Version in Ihrer Installation, nicht gegen eine Übersicht im Netz. Auch nicht gegen diese.

Ein Versionsunterschied gehört gleich hier genannt, weil er die Anmeldung betrifft: Der Microsoft-SharePoint-Node lief in Version 1 über den SharePoint-eigenen REST-Dienst, mit eigenem Zugangsdaten-Format samt Tenant-Subdomain. Ab n8n 2.37.0 legt n8n neue SharePoint-Nodes in Version 2 an, die über Microsoft Graph laufen (Stand der n8n-Dokumentation: 27. September 2026). Eine Verhaltensänderung nennt die Dokumentation ausdrücklich: Passen bei Update oder Create or Update mehrere Einträge, bricht Version 2 mit einer Fehlermeldung ab, wo Version 1 bei Create or Update ein Duplikat anlegte. Workflows, die mit Version 1 gebaut wurden, bleiben auf Version 1 und behalten ihre Zugangsdaten; die Zugangsdaten aus Version 1 funktionieren mit Version 2 nicht. Prüfen Sie deshalb, welche Version bei Ihnen läuft.

Wie sich n8n anmeldet: zwei Wege, ein Unterschied, der alles bestimmt

Microsoft Graph kennt zwei Zugriffsszenarien, und die Wahl zwischen ihnen ist die eigentliche Weichenstellung des Projekts.

	Im Namen eines Nutzers	Als eigenständige Anwendung
Microsoft-Begriff	delegierte Berechtigungen	Anwendungsberechtigungen
Wer handelt	die Anwendung im Auftrag eines angemeldeten Nutzers	die Anwendung mit eigener Identität, ohne angemeldeten Nutzer
Reichweite	begrenzt durch die erteilte Berechtigung und die Rechte dieses Nutzers	das, was die erteilte Berechtigung umfasst
Wer stimmt zu	der Nutzer, sofern die Berechtigung keine Administratorzustimmung verlangt und die Einstellungen Ihres Mandanten das zulassen; sonst ein Administrator, der auch für alle Nutzer zugleich zustimmen kann	ausschließlich ein Administrator
In n8n	Microsoft OAuth2	Microsoft Entra Service Principal (App-Only)

Bei der Reichweite zählen beide Halbsätze. Microsoft schreibt einerseits, die Anwendung könne nichts erreichen, was der angemeldete Nutzer nicht auch erreichen könnte – andererseits, die Befugnisse ergäben sich aus der erteilten Berechtigung und den Rechten des Nutzers. Ein Workflow, der im Namen einer Sachbearbeiterin mit der delegierten Berechtigung Mail.Read läuft, sieht laut Microsofts Berechtigungsreferenz nur ihr eigenes Postfach. Ein Funktionspostfach, das ihr freigegeben ist, erreicht er erst mit Mail.Read.Shared; die Postfächer der übrigen Belegschaft, auf die sie selbst keinen Zugriff hat, auch dann nicht. Der Outlook-Zugang von n8n fordert standardmäßig unter anderem Mail.ReadWrite.Shared an, also Lese- und Schreibzugriff auf die Mails, auf die der Nutzer selbst Zugriff hat, einschließlich freigegebener Postfächer; über Custom Scopes lässt sich das enger fassen.

Im zweiten Fall gilt diese Deckelung nicht. Microsofts eigenes Beispiel: Eine Anwendung mit der Anwendungsberechtigung Files.Read.All kann jede Datei der Organisation lesen. Anwendungsberechtigungen für Microsoft Graph dürfen laut Microsoft ohnehin nur ein Privileged Role Administrator, ein Global Administrator oder eine eigens dafür angelegte benutzerdefinierte Rolle erteilen.

Für unbeaufsichtigte Automatisierung ist der zweite Weg der praktikablere, und zwar aus einem konkreten Grund: Es gibt keine Nutzersitzung, die ablaufen kann, und keine Zustimmung, die pro Person verwaltet werden muss. n8n nennt diesen Zugang Microsoft Entra Service Principal (App-Only). Dieser Weg steht aber nicht bei jedem Baustein zur Verfügung. Die n8n-Dokumentation führt zum Stand 27. September 2026 Outlook, Outlook Trigger, Teams, Teams Trigger, SharePoint, OneDrive, OneDrive Trigger, Excel (OneDrive), Excel (SharePoint) und To Do als unterstützt auf; Outlook, Teams, SharePoint und Excel (OneDrive) erst ab Version 2 des jeweiligen Nodes. Bei Excel widerspricht dem Microsoft: Für die Excel-Tabellen-API von Microsoft Graph führt Microsoft den reinen Anwendungszugriff als nicht unterstützt (Stand 28. September 2026). Testen Sie Excel-Workflows mit diesem Zugang deshalb vor dem Einsatz, oder melden Sie den Excel-Node über ein Nutzer- oder Funktionskonto an. Der Entra-ID-Node ist dort nicht gelistet. Welche Version bei Ihnen läuft, sehen Sie nur in Ihrer eigenen Installation. Hinzu kommt: Manches existiert bei Microsoft nur für einen angemeldeten Nutzer und ist ohne Nutzer schlicht nicht verfügbar; auch diese Operationen listet n8n zur Zugangsart auf.

Die Einrichtung findet in Ihrer eigenen Microsoft-Umgebung statt:

1. Im Microsoft-Entra-Admin-Center eine Anwendung registrieren, beschränkt auf das eigene Verzeichnis.
2. Die benötigten Anwendungsberechtigungen hinzufügen – ausdrücklich die Anwendungs-, nicht die delegierten Berechtigungen. Vor n8n 2.40.0 brauchte der Verbindungstest der Zugangsdaten zusätzlich Organization.Read.All oder Directory.Read.All. Ab n8n 2.40.0 (erschienen am 15. September 2026) prüft der Test nur noch, ob sich die Anwendung anmelden kann, und braucht keine eigene Berechtigung.
3. Die Zustimmung für die Organisation erteilen.
4. Ein Client Secret erzeugen (oder ein Zertifikat hochladen) und zusammen mit Verzeichnis- und Anwendungs-ID sowie der Graph-Basis-URL in n8n hinterlegen.

Die Kehrseite des vereinfachten Tests: Ab 2.40.0 besteht er auch dann, wenn eine Berechtigung oder die Zustimmung fehlt. Laut n8n-Dokumentation zeigt sich das erst, wenn ein Node läuft, je nach Node als allgemeiner Berechtigungsfehler von Microsoft Graph oder mit Nennung der fehlenden Berechtigung. Ein grüner Verbindungstest ist deshalb kein Beleg dafür, dass der Workflow durchläuft; testen Sie mit dem ersten echten Node.

Für SharePoint-Zugriffe nennt die n8n-Dokumentation die Berechtigungen Sites.Read.All zum Lesen und Sites.ReadWrite.All zum Schreiben. Wer die Anwendung auf einzelne Sites begrenzen will, vergibt laut Dokumentation Sites.Selected statt der breiten Berechtigung; das unterstützen der Excel-(SharePoint)-Node und der Microsoft-SharePoint-Node ab Version 2. Das geht in zwei Schritten: Erstens wird Sites.Selected einmal als Anwendungsberechtigung hinzugefügt und mit Administratorzustimmung versehen. Zweitens erhält die Anwendung je Site Lese- oder Schreibzugriff, per Microsoft-Graph-Aufruf POST /sites/{site-id}/permissions oder per PnP PowerShell. Für diesen zweiten Schritt gibt es laut n8n-Dokumentation keine Seite im Entra- oder SharePoint-Admin-Center; fehlt er, scheitert die Operation mit einem 403-Fehler. Mit Sites.Selected können die Nodes allerdings keine Sites suchen oder auflisten. Für den Microsoft-SharePoint-Node in Version 1 nennt die Dokumentation zusätzlich die delegierten Berechtigungen SearchConfiguration.Read.All beziehungsweise SearchConfiguration.ReadWrite.All sowie die Tenant-Subdomain.

Die Anmeldung im Namen eines Nutzers einrichten

Der delegierte Weg läuft in n8n über die Zugangsart Microsoft OAuth2. Wer n8n selbst betreibt, registriert dafür laut n8n-Dokumentation ebenfalls eine Anwendung in Entra ID. Die n8n-Anleitung weicht dabei unter anderem beim Kontotyp der Registrierung vom App-Only-Weg ab; für den Betrieb entscheidend sind drei Schritte:

1. Redirect-URL eintragen. Die n8n-Zugangsdaten zeigen eine OAuth Callback URL. Sie wird bei der Registrierung als Redirect URI mit der Plattform „Web” eingetragen.
2. Scopes statt Anwendungsberechtigungen. Beim generischen Zugang Microsoft OAuth2 tragen Sie die Rechte selbst ins Feld Scope ein, beim SharePoint-Node ab Version 2 etwa openid offline_access Sites.ReadWrite.All; offline_access braucht der Zugang laut Dokumentation, damit er seine Tokens erneuern kann. Die node-eigenen Zugänge, etwa für Outlook oder Teams, bringen Standard-Scopes mit, die sich über Custom Scopes anpassen lassen.
3. Anmelden und zustimmen. Mit Connect my account meldet sich ein Nutzer bei Microsoft an und stimmt den Rechten zu.

Ob der Nutzer selbst zustimmen darf, hängt vor allem an zwei Dingen: Die Berechtigung darf keine Administratorzustimmung verlangen, und die Einstellungen zur Benutzerzustimmung Ihres Mandanten müssen es zulassen. Verlangt die Anwendung in Ihrem Mandanten eine Benutzerzuweisung, muss laut Microsoft ohnehin ein Administrator zustimmen. Manche delegierte Berechtigung verlangt die Administratorzustimmung ausdrücklich, darunter Group.ReadWrite.All und ChannelMessage.Read.All, die der Teams-Zugang von n8n standardmäßig anfordert. Erscheint bei der Anmeldung der Hinweis, dass eine Administratorfreigabe nötig ist, muss ein Administrator die Zustimmung für die Organisation erteilen. Für delegierte Berechtigungen genügt dafür laut Microsoft ein Cloud Application Administrator oder Application Administrator; einen Privileged Role Administrator oder Global Administrator brauchen erst die Anwendungsberechtigungen für Microsoft Graph.

Für den Betrieb heißt das: Der Workflow hängt an einer Person. Laut n8n-Dokumentation zum SharePoint-Node hört er auf zu arbeiten, wenn die Sitzung dieses Nutzers widerrufen wird, etwa weil er das Unternehmen verlässt oder sein Passwort zurückgesetzt wird.

Das Client Secret läuft ab

Beide Wege weisen die registrierte Anwendung gegenüber Microsoft mit einem Client Secret oder einem Zertifikat aus. Secret wie Zertifikat haben ein Ablaufdatum; laut n8n-Dokumentation hört ein App-Only-Workflow auf zu arbeiten, wenn eines davon abläuft. Im Entra Admin Center lässt sich ein Client Secret laut Microsoft höchstens 24 Monate gültig setzen; Microsoft empfiehlt weniger als 12. Für produktive Anwendungen rät Microsoft ganz von Client Secrets ab und empfiehlt Zertifikate oder föderierte Anmeldeinformationen. Beide n8n-Zugangsarten nehmen alternativ ein Zertifikat an.

Ist das Secret abgelaufen, scheitert laut n8n-Dokumentation schon die Anmeldung, erkennbar am Microsoft-Fehlercode AADSTS7000222. Drei Vorkehrungen, bevor der erste Workflow produktiv geht; für ein Zertifikat gelten sie genauso:

• Das Ablaufdatum des Secrets dort notieren, wo es jemand vor dem Stichtag sieht, und die Verantwortung für die Erneuerung einer Person zuweisen.
• Vor dem Ablauf ein neues Secret anlegen und in den n8n-Zugangsdaten eintragen. Microsoft zeigt den Wert eines Secrets nur einmal an, direkt nach dem Anlegen.
• Nach dem Tausch die Zugangsdaten in n8n neu testen. Beim App-Only-Weg speichert n8n das Zugriffstoken zwischen; greift der neue Wert nicht, hilft laut Dokumentation, die Zugangsdaten neu anzulegen.

Die Frage, auf die Ihr Administrator kommen wird

„Heißt das, dieses Werkzeug kann dann alle Postfächer lesen?” Bei einer unbeschränkt erteilten Anwendungsberechtigung: ja. Und das ist der Punkt, an dem ein Automatisierungsvorhaben entweder unnötig scheitert oder unnötig weit aufmacht – wenn beide Seiten annehmen, es gebe nur ganz oder gar nicht.

Es gibt einen Mittelweg, und er ist von Microsoft dafür vorgesehen. Exchange Online kennt eine rollenbasierte Zugriffssteuerung für Anwendungen (RBAC for Applications). Ein Administrator vergibt darin eine Rolle wie Application Mail.Read, Application Calendars.Read oder Application Contacts.Read an die registrierte Anwendung, gekoppelt an einen Ressourcenbereich, der festlegt, auf welche Postfächer sie zugreifen darf. Den Bereich definiert er als Filter über Postfacheigenschaften, etwa die Mitgliedschaft in einer Gruppe, oder über eine Verwaltungseinheit in Microsoft Entra ID. Wichtig für die Erwartung: Dieser Weg betrifft Daten in Exchange Online – Postfächer, Kalender, Kontakte. Für Dateizugriffe wie das Files.Read.All von eben ist Sites.Selected mit der Freigabe je Site das Gegenstück, wo n8n über Graph auf SharePoint-Sites zugreift – vergeben statt der breiten Berechtigung, nicht zusätzlich. Denn laut Microsoft kann eine Anwendung mit Files.Read.All auf die Dateien zugreifen, sobald der Berechtigung zugestimmt ist; Sites.Selected daneben engt das nicht ein. Eine bereits erteilte Files.Read.All, Sites.Read.All oder Sites.ReadWrite.All muss also entfernt werden.

Drei Dinge dazu, die im Projekt leicht untergehen.

Vergeben wird die Rolle nicht in Entra ID, sondern in Exchange Online. In Microsofts Anleitung (dort am Beispiel des SMTP-Versands) legt der Exchange-Administrator in Exchange Online PowerShell zuerst eine Referenz auf den Service Principal der Anwendung an (New-ServicePrincipal), dann den Bereich (New-ManagementScope mit Filter) und weist schließlich die Rolle zu (New-ManagementRoleAssignment mit -App und dem Bereich). Die App-Registrierung und etwaige weitere Berechtigungen, etwa für SharePoint, laufen dagegen in Entra ID. Klären Sie vor dem Termin, wer in Ihrem Haus welchen der beiden Teile ausführen darf; sonst verlieren Sie eine Abstimmungsrunde.

Die breite Erteilung in Entra ID muss weg. Die Anwendungsberechtigung Mail.Read beschreibt Microsoft als Lesezugriff auf alle Postfächer ohne angemeldeten Nutzer. Soll die Anwendung nur ausgewählte Postfächer sehen, entfernen Sie diese Erteilung in Entra ID und vergeben den Zugriff über die Exchange-Rolle. Die n8n-Dokumentation empfiehlt zur Eingrenzung noch die Application Access Policies von Exchange (Stand 27. September 2026); Microsoft rät, keine neuen mehr anzulegen, weil RBAC for Applications sie ersetzt.

Prüfen Sie beide Seiten. Der Befehl Test-ServicePrincipalAuthorization zeigt, welche Exchange-Rollen die Anwendung in welchem Bereich hat, und mit einem angegebenen Postfach, ob dieses im Bereich liegt. Ob die breite Erteilung in Entra ID wirklich entfernt ist, zeigt er nicht; das prüfen Sie auf der Seite API permissions der App-Registrierung. Testen Sie danach im Workflow mit einem Postfach außerhalb des Bereichs. Weil n8n das Zugriffstoken zwischenspeichert, kann ein Test direkt nach der Änderung noch mit dem alten Token laufen; die n8n-Dokumentation empfiehlt in solchen Fällen, die Zugangsdaten neu anzulegen, um ein frisches Token zu erzwingen.

Wenn es für etwas keinen fertigen Baustein gibt

Microsoft 365 ist größer als die Liste oben, und nicht für jede Funktion existiert ein eigener Node. Für diesen Fall gibt es in n8n den HTTP-Request-Node: Er ruft beliebige Schnittstellen auf und kann dabei eine bereits eingerichtete n8n-Zugangsberechtigung wiederverwenden – in der Dokumentation „Predefined Credential Type” genannt und von n8n ausdrücklich gegenüber generisch konfigurierten Zugängen empfohlen.

Praktisch heißt das: dieselben Zugangsdaten und damit dieselben erteilten Berechtigungen, aber Zugriff auf Graph-Funktionen, für die es noch keinen fertigen Baustein gibt. Eine fehlende Integration ist damit ein Aufwandsthema, kein Ausschlusskriterium – ein Unterschied, der bei der Bewertung eines Vorhabens leicht untergeht.

Drei Fragen, bevor der erste Workflow gebaut wird

1. In wessen Namen soll der Workflow handeln? Im Namen eines Mitarbeiters oder als eigenständige Anwendung? Diese Entscheidung bestimmt Reichweite, Zustimmungsprozess und Betriebssicherheit – und sie legt fest, welche Operationen Ihnen überhaupt zur Verfügung stehen.
2. Auf welchen Ausschnitt darf die Anwendung zugreifen – und ist die unbeschränkte Erteilung danach entfernt? Der zweite Halbsatz ist der, der in der Umsetzung leicht untergeht.
3. Welche Node-Versionen laufen in Ihrer Installation? Davon hängt ab, welcher Anmeldeweg pro Baustein zur Verfügung steht. Welche Version welchen Weg unterstützt, steht in der n8n-Dokumentation; welche bei Ihnen läuft, sehen Sie nur in Ihrer Installation.

Und eine vierte, die keine technische ist: Wer bemerkt es, wenn der Workflow stehen bleibt? Ein Automatisierungs-Workflow ist ein Betriebsgegenstand, kein abgeschlossenes Projekt – Zugangsdaten laufen ab (siehe oben zum Client Secret), Schnittstellen ändern sich. Wir haben diese Frage unter den teuersten Fehlern bei der KI-Einführung beschrieben, weil sie sich erst im laufenden Betrieb bemerkbar macht.

Für den Mittelstand heißt das

Die Anbindung an Microsoft 365 ist weniger eine Werkzeugfrage als eine Berechtigungsfrage. Dass n8n mit Outlook, Teams und SharePoint spricht, ist technisch geklärt und dokumentiert – interessant wird es erst bei der Frage, wie eng der Zugang geschnitten ist und wer ihn betreut. Planen Sie ein, dass die Abstimmung darüber, welchen Ausschnitt die Automatisierung sehen darf, länger dauern kann als die technische Anbindung. Bauen Sie auf denselben SharePoint-Daten einen internen Wissensassistenten, reicht ein eng geschnittener Zugang allein nicht mehr aus – dort muss die Berechtigungsprüfung bis in die einzelne Antwort hinein mitlaufen, wie unser Beitrag zum RAG-Wissensassistenten auf SharePoint-Daten zeigt.

Der zweite Punkt betrifft die Erwartungshaltung an das eigene Setup: Sie behalten Ihre Microsoft-Welt. Eine Automatisierungsschicht ersetzt keine Postfächer, keine Teams-Struktur und keine Dokumentenbibliotheken – sie liest aus ihnen, schreibt in sie zurück und verbindet sie mit dem, was daneben liegt: dem ERP, der Warenwirtschaft, dem Ticketsystem, der Buchhaltung, einem Sprachmodell. An dieser Nahtstelle entsteht der Nutzen, weil dort Ihre Fachsysteme an Microsoft 365 andocken. Wovon es abhängt, ob sich ein Fachsystem überhaupt anbinden lässt, haben wir für DATEV und das ERP einzeln aufgeschlüsselt.

Und der dritte: Fangen Sie klein an. Ein einzelner Prozess, ein eng geschnittener Zugang, ein messbares Ergebnis – das ist belastbarer als eine Plattformentscheidung auf dem Papier. Ein gutes Beispiel dafür, wie sich die Wahl zwischen delegierten und Anwendungsberechtigungen ganz praktisch auswirkt, ist eine Excel-Freigabe mit Frist: Ob sie per Mail oder per Teams-Chat läuft, entscheidet auch, ob sie unbeaufsichtigt laufen kann. Welches Werkzeug zu Ihrer Ausgangslage passt, haben wir im Vergleich von n8n, Make und Power Automate aufgeschlüsselt; wie ein Einstieg strukturiert abläuft, beschreibt unser Leitfaden zur KI-Einführung in fünf Phasen. Wenn die Automatisierung anschließend nicht nur Regeln abarbeiten, sondern selbst entscheiden soll, lohnt vorab die Abgrenzung: Was ist eigentlich ein KI-Agent?

FAQ

Müssen wir Microsoft 365 verlassen, wenn wir n8n einsetzen?

Nein. n8n greift auf Ihre bestehenden Dienste über die Schnittstellen zu, die Microsoft dafür bereitstellt – bei Outlook, Teams, OneDrive und Excel über Microsoft Graph. Der SharePoint-Node läuft ab n8n 2.37.0 in Version 2 ebenfalls über Graph; Workflows, die mit Version 1 gebaut wurden, nutzen weiter den SharePoint-eigenen REST-Dienst. Outlook, Teams und SharePoint bleiben unverändert und für die Daten führend; die Automatisierung liegt als zusätzliche Schicht darüber. Beachten Sie aber, dass n8n die verarbeiteten Inhalte standardmäßig in seinem Ausführungsprotokoll speichert; wie lange, hängt bei selbst betriebenem n8n an den Einstellungen, bei n8n Cloud am Tarif.

Welche Microsoft-Dienste deckt n8n mit eigenen Bausteinen ab?

Laut n8n-Dokumentation, Stand 27. September 2026, gibt es unter anderem eigene Nodes für Outlook, Teams, SharePoint, Excel (OneDrive), Excel (SharePoint), OneDrive, To Do und Microsoft Entra ID. Der genaue Funktionsumfang hängt an der Node-Version in Ihrer Installation.

Braucht die Anbindung einen Microsoft-365-Administrator?

Für den unbeaufsichtigten Betrieb ja. Anwendungsberechtigungen für Microsoft Graph können laut Microsoft unter den eingebauten Rollen nur von einem Privileged Role Administrator oder einem Global Administrator erteilt werden, alternativ über eine eigens angelegte benutzerdefinierte Rolle. Läuft der Workflow dagegen im Namen eines angemeldeten Nutzers, kann der Nutzer selbst zustimmen, sofern die Berechtigung keine Administratorzustimmung verlangt und die Einstellungen Ihres Mandanten das zulassen. Die Begrenzung auf einzelne Postfächer richtet zusätzlich ein Administrator in Exchange Online ein.

Kann der Zugriff auf einzelne Postfächer beschränkt werden?

Ja. Exchange Online bietet eine rollenbasierte Zugriffssteuerung für Anwendungen, bei der eine Rolle wie Application Mail.Read an einen definierten Ressourcenbereich gekoppelt wird – etwa an einen Filter über Postfacheigenschaften oder an eine Verwaltungseinheit. Die in Entra ID erteilte Anwendungsberechtigung Mail.Read beschreibt Microsoft dagegen als Lesezugriff auf alle Postfächer. Soll die Anwendung nur ausgewählte Postfächer sehen, entfernen Sie diese Erteilung in Entra ID und prüfen danach sowohl dort als auch mit Test-ServicePrincipalAuthorization, welcher Zugriff übrig ist.

Ersetzt n8n Power Automate?

Nicht zwangsläufig – beide lassen sich parallel betreiben, und das kann der pragmatische Weg sein. Welche Kriterien für welches Werkzeug sprechen, haben wir im Tool-Vergleich anhand der Angaben der jeweiligen Anbieter aufgeschlüsselt.

Was passiert, wenn n8n für eine Microsoft-Funktion keinen fertigen Baustein hat?

Dann übernimmt der HTTP-Request-Node. Er ruft die Schnittstelle direkt auf und kann dabei eine bereits eingerichtete Microsoft-Zugangsberechtigung wiederverwenden. Die Reichweite ändert sich dadurch nicht: Sie hängt an der registrierten Anwendung und den dort erteilten Berechtigungen, nicht daran, welcher Baustein den Aufruf absetzt.