Urlaubsanträge automatisieren: was n8n leisten kann, wo Vertretung und Rollen zählen
n8n-Workflow für Urlaubsanträge: Formular, Kalenderprüfung auf Überschneidung, Genehmigung per Chat – plus Matrix, wann Automatisierung allein reicht.
Urlaubsanträge automatisieren heißt im Kern: Ein Formular löst eine Kalenderprüfung auf Überschneidung aus, und erst danach entscheidet ein Mensch über die Genehmigung. n8n hat dafür keinen eigenen Baustein – Formular, Kalenderabgleich und Chat-Genehmigung kommen aus drei unterschiedlichen Nodes, die Sie selbst verbinden, und für Microsoft Teams gilt dabei eine Zugangsberechtigungsgrenze, an der dieser Schritt mit einer Fehlermeldung scheitern kann.
Dieser Beitrag zeigt den Aufbau Node für Node, ein Entscheidungswerkzeug, mit dem Sie festlegen, wann ein Antrag automatisch durchläuft und wann ein Mensch entscheiden muss, und wo eine fertige Abwesenheits-Software den Eigenbau schlägt. Wie bei anderen n8n-Projekten im Mittelstand gilt auch hier: erst der einfachste, risikoärmste Baustein, dann der Rest – unser Leitfaden zur n8n-Einführung beschreibt diesen Fahrplan allgemein.
Was bei einem Urlaubsantrag zusammenkommt
„Urlaubsanträge automatisieren“ klingt nach einem einzigen Formular. In Wirklichkeit hängen fünf Schritte aneinander, von denen jeder einen anderen Node-Typ braucht:
| Schritt | Was passiert | n8n-Baustein |
|---|---|---|
| 1. Antrag stellen | Mitarbeitende tragen Zeitraum, Abwesenheitsart und Vertretung ein | Form Trigger |
| 2. Überschneidung prüfen | Liegt im selben Team bereits eine genehmigte Abwesenheit im gewünschten Zeitraum? | Google-Calendar- oder Outlook-Node (mit Einschränkung, siehe unten) |
| 3. Genehmigung einholen | Vorgesetzte Person bestätigt oder lehnt ab | Slack- oder Teams-Node, Operation „Send and Wait for Response“ |
| 4. Eskalieren, falls keine Antwort kommt | Die genehmigende Person ist selbst abwesend | Eigenes Statusregister statt eines undokumentierten Zeitgrenzen-Verhaltens (Details unten) |
| 5. Nach der Genehmigung | Kalendereintrag anlegen, Lohnbuchhaltung informieren | Calendar-Node (Create), Send-Email-Node |
Keiner dieser fünf Schritte ist mit einem einzigen Node erledigt. Die Qualität des Workflows entscheidet sich daran, wie sauber die Übergänge zwischen ihnen sind – nicht daran, ob überhaupt ein Formular existiert.
Der technische Aufbau in n8n
1. Formular als Auslöser
Der Form Trigger erzeugt die Eingabeseite selbst und startet den Workflow bei jeder Einreichung. Für einen Urlaubsantrag braucht das Formular mindestens: Start- und Enddatum, Abwesenheitsart (als Dropdown, zum Beispiel Urlaub, Sonderurlaub, Homeoffice) und ein Feld für die vorgeschlagene Vertretung. Ein Detail, das bei der Planung leicht übersehen wird: Die vollständige Feldtypen-Liste der n8n-Dokumentation führt für den Form Trigger ein Datumsfeld mit Kalender-Auswahl, aber keinen eigenen Datumsbereich-Typ. Ein Urlaubsantrag braucht deshalb zwei separate Date-Felder – Start und Ende –, kein einzelnes „Zeitraum“-Feld. Jedes Feld lässt sich einzeln als Pflichtfeld markieren.
2. Überschneidung im Kalender prüfen
Hier unterscheiden sich die beiden Microsoft-365- und Google-Welten spürbar. Der Google-Calendar-Node bringt unter der Ressource „Calendar“ eine eigene Operation „Availability“ mit: Sie geben Kalender, Startzeit und Endzeit an, und der Node meldet laut Dokumentation, ob es im angefragten Zeitraum bereits überlappende Termine gibt – wahlweise als reine Verfügbarkeitsaussage, als Liste der belegten Zeiträume oder als Rohdaten der API.
Der Microsoft-Outlook-Node hat keine entsprechende Operation. Seine Ressourcen Calendar und Event bieten beide nur Create, Delete, Get, Get Many und Update – eine Verfügbarkeits- oder Frei/Besetzt-Prüfung ist in der n8n-Dokumentation nicht aufgeführt. Wer mit Microsoft 365 arbeitet, braucht für dieselbe Prüfung einen HTTP-Request-Node direkt gegen Microsoft Graph: Die Funktion getSchedule (POST /users/{id}/calendar/getSchedule) liefert für eine Liste von Personen in einem einzigen Aufruf den Frei/Besetzt-Status je Zeitfenster zurück, mit dem Status busy, free, tentative oder workingElsewhere pro Eintrag. Das ist mehr, als eine einfache Ja/Nein-Prüfung bräuchte – aber ohne diesen Umweg über das HTTP-Request-Node bleibt die Überschneidungsprüfung in der Outlook-Welt ein manueller Blick in den Kalender.
3. Genehmigung per Chat – und ihre Grenze bei App-Only-Zugangsdaten
Sowohl der Slack- als auch der Teams-Node bieten eine Operation „Send and Wait for Response“: Der Node schickt eine Nachricht und hält den Workflow an, bis die genehmigende Person reagiert. Bei Slack aktiviert die Option „Capture Who Responded“ interaktive Buttons direkt in Slack; die Antwort kommt über einen Rückruf an /webhook-waiting-slack, den n8n über das Signing Secret der Zugangsberechtigung prüft – die n8n-Instanz muss dafür öffentlich über HTTPS erreichbar sein. Aufgezeichnet werden unter anderem, ob genehmigt wurde, der Zeitpunkt und wer geantwortet hat.
Bei Microsoft Teams sitzt dieselbe Operation unter der Ressource „Chat Message“, mit drei Antworttypen: Approval, Free Text oder Custom Form. Hier liegt die Falle, die in einem Microsoft-365-Projekt leicht übersehen wird: Läuft Ihre n8n-Instanz mit einer Service-Principal-Zugangsberechtigung (App-Only, wie sie unser Beitrag zur n8n-Microsoft-365-Anbindung für den eigenständigen, von keiner Person abhängigen Betrieb beschreibt), ist die gesamte Chat-Message-Ressource laut n8n-Dokumentation nicht verfügbar – wörtlich: „the node sends and reads chat messages as the signed-in user“. Der Genehmigungsschritt über Teams-Chat braucht also zwingend eine Teams-OAuth2- oder eine delegierte Microsoft-Zugangsberechtigung, im Namen einer angemeldeten Person. Wer den Workflow mit App-Only-Zugangsdaten baut, weil der Rest der Microsoft-365-Anbindung damit läuft, stößt an genau dieser Stelle auf einen Fehler, der sich nicht durch eine andere Teams-Operation umgehen lässt – nur durch einen zweiten, delegierten Zugangsdatensatz für diesen einen Schritt.
4. Vertretung, wenn niemand antwortet
Was, wenn die genehmigende Person selbst im Urlaub ist? Das hängt vom Chat-Dienst ab, und keine der beiden Antworten ist vollständig dokumentiert. Teams bietet für „Send and Wait for Response“ eine eigene Option „Limit Wait Time“, die den Workflow nach einem Intervall oder zu einem festen Zeitpunkt automatisch fortsetzt – für alle drei Antworttypen. Was dabei als Antwort gilt, sagt die Dokumentation aber nicht: ob sie als abgelehnt zählt, leer bleibt oder der Workflow einfach mit dem nächsten Schritt weiterläuft. Für Slack ist in der Dokumentation – weder auf der Hauptseite noch auf der separaten Approvals-Detailseite – eine entsprechende Zeitgrenzen-Option zu finden.
Verlassen Sie sich deshalb nicht auf ein Verhalten, dessen Ausgang die Dokumentation offenlässt. Verlässlicher ist ein eigenes, davon unabhängiges Statusregister: Der Genehmigungsschritt schreibt seinen Status in ein Register (ähnlich der Statusspalte „Letzte Erinnerung“ aus unserem Beitrag zur Vertragsfristen-Überwachung), und ein separat zeitgesteuerter Zweig mit dem Wait-Node – Resume-Einstellung „After Time Interval“ oder „At Specified Time“, unabhängig von jedem Webhook oder Formular – prüft nach Ablauf einer von Ihnen festgelegten Frist, ob dort noch immer „offen“ steht. (Die Option „Limit Wait Time“ gehört an anderer Stelle der Wait-Node-Dokumentation dazu, nämlich als Rückfall-Zeitgrenze innerhalb der Resume-Arten „On Webhook Call“ und „On Form Submitted“ – für den hier beschriebenen, eigenständigen Zweig ist sie nicht nötig.) Ist das der Fall, geht dieselbe Anfrage an die hinterlegte Vertretung. Das ist unabhängig vom Chat-Dienst dieselbe, zusätzliche Konstruktion – wer sie weglässt, überlässt dem jeweiligen Chat-Node ein Verhalten, das niemand im Workflow kontrolliert.
5. Nach der Genehmigung: Kalendereintrag und Information
Nach einer positiven Antwort legt der jeweilige Calendar-Node (Google: Event-Ressource, Operation Create; Outlook: Event-Ressource, Operation Create) den Termin im Teamkalender an, sichtbar für alle, die bei Schritt 2 mitgeprüft werden sollen. Eine Information an die Lohnbuchhaltung läuft über denselben Send-Email-Weg, den auch andere HR-Workflows nutzen – kein eigener Baustein nötig, nur eine weitere Mail mit den bereits vorliegenden Antragsdaten.
Entscheidungswerkzeug: wann automatisch, wann ein Mensch entscheidet
Nicht jeder Antrag verdient dieselbe Prüftiefe. Diese Matrix ordnet nach dem Risiko eines falschen „automatisch durch“ – nicht danach, was technisch am einfachsten zu bauen ist:
| Situation | Automatisch durchlaufen? | Was der Workflow dafür braucht |
|---|---|---|
| Keine Überschneidung im Team, Vertretung im Formular bereits benannt | Ja – Vorgesetzte Person wird nur informiert, nicht gefragt | Kalenderprüfung negativ und ein ausgefülltes Vertretungsfeld |
| Überschneidung im Team, aber unterhalb einer von Ihnen festgelegten Mindestbesetzung | Nein – Vorschlag an die vorgesetzte Person, die entscheidet | Kalenderprüfung zeigt die übrigen anwesenden Personen, nicht nur „Konflikt ja/nein“ |
| Person in einer Schlüsselrolle ohne bestätigte Vertretung | Nein, immer Eskalation vor der Genehmigung | Eine Rollen-Kennzeichnung, die der Workflow vor der Genehmigung abfragt – aus dem Formular oder einer Stammdaten-Quelle |
| Resturlaub nahe einer intern bestätigten, personenbezogenen Frist | Zusätzlicher Hinweis, nie eine Blockade | Eine von der Personalabteilung gepflegte Frist je Person, keine geschätzte oder von einer Wettbewerberseite übernommene |
Der Unterschied zu den Anbieterseiten, die für dieselbe Suche ranken: Sie beschreiben die Kette Vertretung → Genehmigung → Überschneidung → Kalender als linearen Ablauf oder als Produktfunktion, ohne eine Regel dafür zu nennen, wann ein Schritt automatisch laufen darf und wann nicht. Diese Matrix macht genau diese Grenze explizit – und sie lässt sich direkt auf die Nodes aus dem Abschnitt oben abbilden.
Resturlaubsfristen: was die Automatisierung beitragen kann
Ob und wann Resturlaub verfällt, ist eine arbeitsrechtliche Frage, die von Gesetz, Tarifvertrag, Betriebsvereinbarung und dem Einzelfall abhängt. Das klärt Ihre Personalabteilung oder eine arbeitsrechtliche Beratung – nicht dieser Beitrag, und nicht der Workflow. Was die Automatisierung beitragen kann, ist technisch bescheiden, aber nützlich: eine von Ihnen bestätigte, personenbezogene Frist je Mitarbeitendem hinterlegen und rechtzeitig vorher erinnern, nach demselben Muster wie die Fristüberwachung bei Verträgen. Der entscheidende Unterschied zu einer bequemen Abkürzung: Diese Frist kommt aus Ihrer eigenen, geprüften Quelle – nie aus einer geschätzten Regel oder aus dem, was eine Anbieterseite als allgemeine Aussage nennt. Ein Workflow, der ein falsches Datum zuverlässig pünktlich meldet, ist nicht hilfreicher als gar keine Erinnerung.
Für den Mittelstand heißt das
Fangen Sie mit dem Schritt an, der am wenigsten Urteilsvermögen braucht: der Überschneidungsprüfung im Kalender. Sie liefert nur eine Information, trifft keine Entscheidung, und genau deshalb lässt sie sich am leichtesten zuverlässig bauen und am leichtesten prüfen, ob sie stimmt. Die Genehmigung selbst bleibt dort ein Mensch, wo es um echtes Urteilsvermögen geht – Schlüsselrollen ohne Vertretung, enge Teambesetzung, eine Frist, die eine rechtliche Prüfung braucht. Ein Workflow, der versucht, auch diese Fälle automatisch durchzuwinken, verlagert das Risiko, ohne es zu verringern.
Und: Je mehr Sonderregeln ein Eigenbau am Ende abbildet – mehrstufige Vertreterketten, Obergrenzen je Abteilung, ein geprüfter Audit-Trail für die Lohnbuchhaltung –, desto näher rückt er an das, was eine fertige Abwesenheits-Software als Produkt bereits mitbringt. Der Eigenbau aus diesem Beitrag lohnt sich für den einfachen Fall: eine Genehmigungsebene, wenige Vertretungsregeln, bestehende Google- oder Microsoft-365-Kalender. Sobald die Sonderregeln die Mehrheit der Fälle ausmachen, ist die Frage nicht mehr „Welcher Node fehlt noch?“, sondern „Lohnt sich der Eigenbau gegenüber einer Lizenz noch?“
FAQ
Hat n8n einen eigenen Baustein für Urlaubsanträge?
Nein. Es gibt keinen Node, der einen Urlaubsantrag als Ganzes abbildet. Der Workflow entsteht aus mehreren Standard-Nodes: einem Formular für den Antrag, einem Kalender-Node für die Überschneidungsprüfung und einem Chat-Node für die Genehmigung – jeder deckt nur seinen Teilschritt ab.
Kann die Genehmigung über Microsoft Teams laufen?
Ja, über die Operation „Send and Wait for Response“ des Teams-Node, mit Antworttyp Approval, Free Text oder Custom Form. Nicht mit einer Service-Principal-Zugangsberechtigung (App-Only): Laut n8n-Dokumentation ist die gesamte Chat-Message-Ressource damit nicht verfügbar, weil der Node Chatnachrichten nur im Namen einer angemeldeten Person sendet und liest. Für den Genehmigungsschritt brauchen Sie deshalb eine Teams-OAuth2- oder eine delegierte Microsoft-Zugangsberechtigung.
Was passiert, wenn die genehmigende Person selbst abwesend ist und nicht antwortet?
Das hängt vom Chat-Dienst ab, und keine der beiden Antworten ist vollständig dokumentiert. Teams bietet für „Send and Wait for Response“ eine eigene Option „Limit Wait Time“, die den Workflow nach einem Intervall oder zu einem festen Zeitpunkt automatisch fortsetzt – was dabei als Antwort gilt, sagt die Dokumentation aber nicht. Für Slack ist in der Dokumentation keine entsprechende Zeitgrenzen-Option zu finden. Verlässlicher ist deshalb ein eigenes, davon unabhängiges Statusregister: Der Genehmigungsschritt schreibt seinen Status in eine Spalte, und ein separat zeitgesteuerter Zweig mit dem Wait-Node prüft nach einer von Ihnen festgelegten Frist, ob dort noch „offen“ steht – nach demselben Register-Muster wie bei der Vertragsfristen-Überwachung.
Prüft n8n automatisch, ob Resturlaub bald verfällt?
Nur technisch, nie rechtlich: Ein Workflow kann eine von Ihnen hinterlegte, personenbezogene Frist überwachen und rechtzeitig erinnern – wie bei der Vertragsfristenüberwachung. Ob und wann Resturlaub tatsächlich verfällt, ist eine arbeitsrechtliche Frage, die Ihre Personalabteilung oder eine arbeitsrechtliche Beratung für Ihren Einzelfall klärt, nicht dieser Beitrag. Eine geschätzte oder von einer Anbieterseite übernommene Frist gehört nicht in den Workflow.
Reicht der n8n-Eigenbau, oder brauche ich eine fertige Abwesenheits-Software?
Für ein Team mit einer Genehmigungsebene und wenigen Vertretungsregeln trägt der Eigenbau aus Formular, Kalenderprüfung und Chat-Genehmigung. Je mehr Sonderregeln dazukommen – mehrstufige Vertreterketten, Obergrenzen je Abteilung, eine Anbindung an die Lohnbuchhaltung mit Audit-Trail –, desto eher lohnt sich eine fertige Abwesenheits-Software, die das als Produkt mitbringt, statt es Stück für Stück nachzubauen.
Quellen
- n8n-Dokumentation: Form Trigger Node (vollständige Feldtypen-Liste: Checkboxes, Custom HTML, Date, Dropdown, Email, File, Hidden Field, Number, Password, Radio Buttons, Text, Textarea – ein eigener Datumsbereich-Typ ist darin nicht aufgeführt; zu Date wörtlich „Select Date to include a date picker in the form.“; jedes Feld hat einen Required-Field-Schalter), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Google Calendar Node (Ressource Calendar mit der Operation Availability, Ressource Event mit Create/Delete/Get/Get Many/Update), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Google Calendar – Calendar-Operationen im Detail (Availability-Parameter Calendar/Start Time/End Time, Ausgabeformat Availability/Booked Slots/RAW), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Microsoft Outlook Node (Ressourcen Calendar und Event, je mit Create/Delete/Get/Get Many/Update; keine Availability- oder Free-Busy-Operation dokumentiert), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Slack Node (Ressource Message, Operation „Send and Wait for Response“), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Approvals in Slack (Antworttyp Approval mit interaktiven Slack-Buttons über „Capture Who Responded“, Rückruf an `/webhook-waiting-slack`, Prüfung über das Signing Secret, aufgezeichnete Felder approved/respondedAt/channel/messageId/responder), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Microsoft Teams Node (Ressource Chat Message mit Create/Delete/Get/Get Many/„Send and Wait for Response“/Undo Delete; Antworttypen Approval, Free Text, Custom Form; Option „Limit Wait Time“ – automatische Fortsetzung nach Intervall oder festem Zeitpunkt, für alle drei Antworttypen, Ausgang bei Fristablauf nicht dokumentiert; Service-Principal-Abschnitt wörtlich: „Chat Message: not available. The node sends and reads chat messages as the signed-in user.“), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Microsoft Entra Service Principal credentials (Chat, Chat Member und Chat Message sind mit dieser Zugangsberechtigung nicht verfügbar – wörtlich „Microsoft Teams: the whole Chat, Chat Member, and Chat Message resources“), abgerufen am 23. Oktober 2026
- n8n-Dokumentation: Wait Node (Resume-Arten After Time Interval/At Specified Time/On Webhook Call/On Form Submitted; „Limit Wait Time“ existiert nur als Rückfall-Zeitgrenze innerhalb von On Webhook Call und On Form Submitted, nicht bei den beiden reinen Zeit-Resume-Arten), abgerufen am 23. Oktober 2026
- Microsoft Graph: calendar – getSchedule (Frei/Besetzt-Information für mehrere Personen in einem Aufruf, `POST /users/{id}/calendar/getSchedule`, Antwort je Person mit scheduleItems-Status busy/free/tentative/workingElsewhere), abgerufen am 23. Oktober 2026