Onboarding and offboarding are usually built as two separate, ad hoc checklists maintained by whoever last got frustrated enough to write one down. This template treats them as one system with two entry points, because the underlying problem, keeping access, equipment and communication in sync with employment status, is the same problem in both directions.
Workflow diagram
flowchart TD
A[New Hire Webhook] --> B[Extract Details]
B --> C[Days Until Start]
C --> D{Within 5 Days?}
D -->|No| E[Wait 1 Day] --> D
D -->|Yes| F[Create Workspace Account]
D -->|Yes| G[Create Slack Account]
D -->|Yes| H{Role-Specific Provisioning}
H -->|Engineering| I[GitHub + AWS Access]
H -->|Sales| J[CRM + Dialer Access]
I --> K[Order Equipment]
J --> K
F --> L[Merge Provisioning]
G --> L
K --> L
L --> M[Schedule Day-1 Events]
M --> N[Assign Buddy]
N --> O[Welcome Email]
P[Termination Webhook] --> Q[Extract Details]
Q --> R{Involuntary?}
R -->|Yes| S[Revoke Access Immediately]
R -->|No| T[Schedule Revocation, Last Day] --> U[Revoke All Access]
S --> V[Retrieve Equipment]
U --> V
V --> W[Transfer File Ownership] Every branch shown here (IF/Switch outcomes) exists as a real conditional in the downloadable JSON, not a simplification for this diagram.
Timing provisioning to start date, not to when someone remembers
New-hire provisioning has a narrow correct window. Too early wastes paid software licenses for someone who has not started, and occasionally exposes internal systems to an account nobody is watching yet. Too late means a new employee's first day is spent waiting for IT instead of working.
The Days Until Start calculation and the Start Date Within 5 Days? loop hold provisioning until exactly five business days before start, then fire the Google Workspace, Slack and role-specific access nodes together. Role-Specific Provisioning branches on department because an engineer and a sales rep need almost entirely different tool access, and hard-coding one generic checklist for both means either engineers get CRM access they do not need or sales reps wait on GitHub permissions nobody will use.
Offboarding: the branch that actually matters for security
The Involuntary Departure? branch is the most operationally important decision in this entire template. An involuntary departure revokes all system access immediately, before the conversation with the employee even happens in some security postures, because the risk of continued access after notice outweighs the inconvenience.
A voluntary departure instead schedules revocation for end of the employee's last working day, using n8n's specific-time Wait node. This lets a departing employee remain productive through their notice period while still guaranteeing access disappears automatically at the right moment, rather than depending on someone remembering to do it manually on a Friday afternoon.
The step almost every offboarding checklist forgets
Transfer File Ownership To Manager exists because of a specific, common failure: a departed employee's Google Drive files are owned by an account that no longer exists, and without an explicit ownership transfer, those files become effectively orphaned. Institutional knowledge, client documents, and project history simply vanish into an inaccessible account.
This step runs for every offboarding, voluntary or not, immediately after equipment retrieval, so file continuity is never dependent on someone remembering to ask for it during an already busy departure process.
Node-by-node reference
| Node | Type | Role |
|---|---|---|
| HRIS New Hire / Termination Webhook | Webhook ×2 | Two independent entry points for the two lifecycle directions |
| Days Until Start | Code | Calculates the countdown to trigger provisioning at the right time |
| Start Date Within 5 Days? | IF (looping) | Holds provisioning until the correct window, avoids early waste |
| Role-Specific Provisioning | Switch | Department-aware branching, engineering vs sales access |
| Involuntary Departure? | IF | The single most important security-relevant branch in the workflow |
| Revoke Access Immediately | HTTP Request | Immediate revocation path for involuntary departures |
| Schedule Revocation For Last Day | Wait (specific time) | Delayed revocation for voluntary departures |
| Transfer File Ownership To Manager | HTTP Request | Prevents departed-employee files becoming inaccessible |
28 total nodes in the downloadable file, including sticky-note documentation embedded directly on the canvas.
Key logic, in code
Start-date countdown (Days Until Start node)
const startDate = new Date($json.startDate);
const today = new Date();
const msPerDay = 1000 * 60 * 60 * 24;
const daysUntilStart = Math.ceil((startDate - today) / msPerDay);
return [{ json: { ...$json, daysUntilStart } }];Before / after
| Metric | Before | After this workflow |
|---|---|---|
| Day-1 readiness | Inconsistent, IT-ticket dependent | Provisioned automatically 5 days out |
| Access revoked after involuntary exit | Minutes to hours, manual | Immediate, automatic |
| Orphaned files after departure | Common | Explicit ownership transfer, every time |
| Equipment tracking | Spreadsheet, often stale | Logged automatically at order and return |
Prerequisites
- n8n v1.40+ with specific-time Wait node support
- Google Workspace Admin SDK access
- Slack Enterprise Grid admin token (for account provisioning, not just messaging)
- GitHub organisation admin token, HubSpot admin access
- An asset-management API for equipment ordering and retrieval
Common pitfalls
Test the involuntary-departure path deliberately
This is the highest-stakes branch in the template. Run it against a test account before your first real involuntary termination, not during one.
Keep the department-provisioning map current
Role-Specific Provisioning only covers what you configure. A new department with no matching case falls through silently, add a default/fallback branch for anything unmapped.
Coordinate offboarding timing with the people conversation
Immediate revocation for involuntary departures should be sequenced with HR and legal guidance on when the employee is actually notified, this is a policy decision, not just a technical one.
Want this deployed, configured and monitored?
The template is free. Wiring in your real credentials, tuning the logic to your business, and keeping it running when an upstream API changes is what we do.
Get my free automation plan →Frequently asked questions
Can this integrate with BambooHR or Workday instead of a generic HRIS?
Yes, most HRIS platforms support outbound webhooks on hire and termination events, only the two trigger nodes need reconfiguring.
What about contractors, not just full-time employees?
Add a worker-type field early in Extract New Hire Details and branch provisioning scope accordingly, contractors typically need a narrower access set.
Does the buddy assignment logic need to be manual?
The template logs to Airtable for a human to assign; you can automate simple round-robin assignment in the same node if your team structure supports it.