Employee onboarding automation

Each task has a different owner and a different failure profile. IT owns account creation, legal owns documents, and HR owns meetings and messaging. With Execute Workflow, each team can change and test its own sub-workflow on its own, with its own retries and credentials. The orchestrator stays small: validate, record status, call sub-workflows, merge results. It also lets me choose per call whether to wait for completion. I wait for accounts and meetings because the welcome message needs their output, but I don't wait for e-signature, which can take days. Executions are easier to debug too, because a failure points to a specific sub-workflow rather than node forty of a giant canvas.

HR submits an n8n Form Trigger with only the fields later steps need. The orchestrator validates them with IF and Code nodes, builds a stable hire ID and upserts a Postgres row that stores a status for each task. It then calls sub-workflows through Execute Workflow. The accounts call waits and returns the work email. E-sign runs without waiting, pausing on a Wait node until the provider's webhook arrives. Meetings books first-week sessions and returns their times. A Merge node combines the account and meeting results, and an AI Agent using Vercel AI Gateway drafts the welcome message. HR approves it through a Wait-for-form link before Gmail sends it. Postgres tracks completion, the manager gets a Slack summary, and an error workflow alerts HR-ops.

The ID must be deterministic, so the same hire always produces the same value. I would use an HR or requisition reference if one exists. Otherwise I would hash a normalised personal email: trimmed and lower-cased. I would not include the start date, because start dates change and a changed ID would start a second onboarding. A random UUID or the execution ID per submission is the classic mistake. Every resubmission then looks like a new person, and you get duplicate Workspace users and duplicate e-sign envelopes. The ID becomes the Postgres primary key, and it is passed to every sub-workflow so each one can check or record status. It also appears in alerts so HR-ops can find the record.

I would use a hires table keyed by hire_id. It holds the submitted fields, the work email once known, an overall status, and created and updated timestamps. A hire_tasks table has one row per hire and task: accounts, esign, meetings, welcome_draft, welcome_approval, welcome_sent and day_one_dm. Each row has a status (pending, in_progress, done or failed), an attempt count, the last error, and external references such as the Workspace user ID, e-sign envelope ID and calendar event IDs. A unique constraint on hire_id plus task makes writes idempotent. Storing the external IDs matters because a rerun can then check or reuse an existing resource instead of creating it again. It also gives HR one status view per hire.

Creating the account and granting access are separate steps. The accounts sub-workflow creates the Google Workspace user in a suspended state, or in an organisational unit with no services enabled. It records the user ID and returns the work email, so the welcome message and calendar invites can reference it. Access is activated on the start date. A Schedule-triggered workflow reads Postgres for hires starting today, in their local time zone, and then unsuspends the user and adds the role groups and Slack channels. I would also use the same check as a guard: an IF node refuses activation if the start date is in the future. This means even a manual rerun cannot grant access early.

I give each hire a stable ID when the form arrives and keep a Postgres row with a status column for each task: accounts, documents, meetings, welcome. Every sub-workflow first reads its status. If the task is already done, it returns the stored result instead of acting again. Before creating a Google Workspace user, it also checks whether that email already exists, because a call can succeed on the provider side even though n8n saw a timeout. Retry-on-fail handles short API errors, and the Error Trigger workflow alerts HR with the execution link. Because status is persisted after each step, a manual rerun or a duplicate form submission only finishes what is still missing.

I limit both what goes in and what can come out. The AI Agent receives only structured facts: first name, role, team, start date, manager name and meeting times. It gets no salary, ID numbers or full HR record. The prompt tells it to use only those facts and to return the message body, while links and dates are inserted by template from the data rather than generated. The call goes through Vercel AI Gateway, so I get fallbacks and spend tracking with one credential. Then a human gate: a Wait node sends HR an approval form, and nothing goes to the new hire until HR approves or edits it. I track how often HR edits drafts to tune the prompt.

The orchestrator needs the work email before it can continue. Meeting invites and the welcome message depend on it, so it must wait for the accounts result. E-sign is different. Its result can take days, because a person has to open and sign the documents, and nothing downstream needs to block on it. If the orchestrator waited, the execution would stay open for days and the welcome message would be held up for no reason. So e-sign runs on its own: it waits on its own Wait node, sends reminders and writes the signed status to Postgres. The manager summary reads that status from the database instead of from the orchestrator's memory.

Before pausing, the sub-workflow sends the envelope to the provider. The callback URL is the execution's $execution.resumeUrl, or the provider's webhook is pointed at a handler that looks up that URL. I store the envelope ID against the hire ID in Postgres. When the callback arrives, I check the provider's signature or a shared secret if the provider supports one. I also confirm that the envelope ID matches the stored record and that the event really means 'completed' and not just 'viewed'. Duplicate callbacks are harmless, because the status update only moves forward. Anything that fails verification is logged and ignored instead of marking documents as signed.

The form collects location, and I map that to an IANA time zone such as Asia/Kolkata. A free-text offset would break on daylight-saving changes for overseas hires. The start date is a local date in the hire's zone. I build event start times in that zone and pass the time zone explicitly to the Google Calendar node, not rely on the n8n instance's default zone. Attendees in other zones see the converted time automatically. I also check the slots against working hours in both the hire's zone and the manager's zone. Meeting times go back to the orchestrator with the zone included, so the welcome message states times the hire will read correctly.

The edited text becomes the message that is sent, so the approval step must store exactly what HR approved. It must not regenerate the draft afterwards. I save the approved text, the approver and a timestamp in Postgres, and Gmail sends that stored version unchanged. The risk is that HR adds a typo in a date, or that a long approval delay leaves the facts out of date because a meeting moved. Before sending, a Code node checks that the start date and meeting times in the approved text still match Postgres. If they do not, it sends the draft back for re-approval instead of sending stale facts. Every send is tied to one approval record.

I would estimate from the hiring rate, not guess numbers. Each hire creates one orchestrator execution plus three or four sub-workflow executions, a few approval and e-sign waits, one model call, and a handful of API calls to Workspace, Slack and Calendar. Even for a company hiring hundreds of people a month, that is a low and bursty volume. The real pressure points are bursts, such as a campus batch joining on the same day, which can hit Google or Slack rate limits, and long-waiting executions. A single n8n instance usually handles this. I would batch bulk imports with Loop Over Items and rely on retries with back-off rather than adding infrastructure.

An IF node that reads 'does this hire exist?' is not enough. Both executions can read 'no' before either one writes. The guarantee has to come from Postgres. I use a primary key on hire_id and an INSERT ... ON CONFLICT upsert. Each task is then claimed with a conditional update, for example setting the status to in_progress only where it is pending, and checking that one row was affected. Only the execution that wins the claim creates the account. The other one sees the task is already in progress and stops or waits. For extra safety, the accounts step also looks up the user by work email in Workspace before creating it.

Each onboarding workflow sets the same error workflow in its settings. That workflow starts with an Error Trigger, which receives the failed execution's details. It posts the hire ID, workflow name, failed node, a short error message and the execution link to the HR-ops Slack channel. It can also mark the task as failed in Postgres, so the status view shows the failure. It should avoid dumping the full item payload, because that would push personal email, location and document details into Slack. It should not try clever automatic fixes. The person handling it opens the execution, fixes the cause and reruns, and stored task status makes that rerun skip completed work.

Retry-on-fail is for transient problems on a single node, such as a 429 rate limit, a 5xx from Google or Slack, or a network timeout. I set a few tries with a wait between them. It is only safe on operations that are idempotent or protected by a prior lookup, because a 'create user' call that timed out may actually have succeeded. The error workflow is for failures retries cannot fix: bad input, revoked credentials, a missing manager, or an exhausted retry budget. Those need a human. So retries absorb noise, and the error workflow makes the remaining failures visible with enough context to act on them.

This is a partial success, and the per-task status model is designed for it. The Workspace step writes 'done' with the user ID right after it succeeds. The Slack step is recorded separately, so its failure leaves that task as failed and the Workspace task untouched. The error workflow alerts HR-ops. When the rerun happens, the accounts sub-workflow sees the Workspace task is done, skips it, and retries only Slack. I would not roll back the Workspace user automatically. Deleting and recreating it adds risk and churn. The orchestrator also does not draft the welcome message until all account tasks it depends on are done.

n8n stores credentials encrypted and nodes reference them by name, so secrets never appear in workflow JSON. On self-hosted instances, the encryption key is kept in a secret manager and backed up. Each credential is least-privilege. The Workspace service account can only manage users in the relevant organisational units. The Slack token has only the scopes needed to invite users and post messages. Calendar access is limited to the accounts doing the booking. The AI Gateway key is the only model credential, and no provider keys live in n8n. I restrict who can edit these workflows and see credentials, and I rotate keys when people leave the team.

It holds the new hire's name, personal email, role, department, manager, start date and location, plus signed documents held by the e-sign provider. I apply data minimisation. The form collects only the fields later steps need. The AI prompt gets only the first name, role, team, start date and meeting times. No personal email or document content goes to the model. Slack messages and alerts carry the hire ID, not the full record. In India, the DPDP Act means we need a clear purpose and defined retention, so I would set execution-data pruning, limit who can view executions, and define how long Postgres keeps records after onboarding finishes.

I would use a separate n8n environment or project with sandbox credentials. That means a test Workspace organisational unit, a test Slack workspace, the e-sign provider's sandbox and a test calendar. I would use pinned data to replay form submissions through the orchestrator. The test cases are: a normal hire, a missing field, the same submission twice, two submissions at the same time, a forced Slack failure followed by a rerun, an e-sign timeout, an approval that never arrives, and a hire in another time zone. For the AI step, I keep a small set of inputs and check the drafts for correct facts. After launch, I would run the first few real hires with HR watching closely.

I set the Wait node's limit-wait-time option. If the webhook has not arrived when the limit passes, the execution continues down the timeout path. An IF node checks whether the resume came from the webhook or from the timeout. On a timeout, it re-checks the envelope status with the provider through HTTP Request, in case a callback was lost. If the documents are still unsigned, it sends a reminder and loops back to wait again. A counter in Postgres caps the number of reminders. After the last one, the workflow alerts HR in Slack instead of nagging the candidate forever. Each reminder is recorded so HR can see what was sent and when.

Before creating events, the meetings sub-workflow checks free/busy for each attendee in the first-week window. Depending on the setup, that uses the Google Calendar node's availability operation or an HTTP Request to the free/busy API. It picks the first slot that works for everyone within working hours after the start time. If no slot fits, it does not double-book. It marks the meeting task as needing attention and posts to HR, so a human can resolve it. Created event IDs are stored in Postgres, so a rerun updates existing events instead of creating duplicate invites.

The approval Wait node has a time limit that depends on how far away the start date is. If it expires, the workflow reminds HR in Slack, and after that escalates to an HR-ops channel. It never sends the message by default. Silence must not count as approval, because the rule is that nothing unapproved goes out. If the start date passes without approval, the welcome email is simply skipped and marked as such in Postgres. The day-one Slack DM is held as well. Account activation and meetings are not blocked by this, because they do not depend on the welcome message.

Before the start date, the new hire cannot log in to the work account. It is suspended until day one so that access is not granted early. So mail sent there would sit unread. The personal email is the address the hire actually checks. The trade-off is that the personal email is personal data, so it is used only for this send and the e-sign envelope. It is not included in the AI prompt, Slack summaries or error alerts. From day one, communication moves to the work identity, which is why the Slack DM is scheduled for the start date.

I would move when executions start competing, for example when large batch joins run alongside other company workflows on the same instance, or when we need high availability. In queue mode, the main instance receives triggers and webhooks and puts executions on a Redis queue, and worker processes run them. Workers can scale horizontally. For this workflow, the design already suits that. State lives in Postgres, not in any one process, and idempotent upserts protect against two workers touching the same hire. Waiting executions are stored in the database, so they resume correctly regardless of which worker picks them up. I would also tune worker concurrency to stay under API rate limits.

The task is short, personalised writing with strict facts, so a capable general model such as anthropic/claude-sonnet-4.5 fits. The best choice is set by testing drafts against real examples, not by assumption. Because Vercel AI Gateway uses one OpenAI-compatible endpoint and one key, switching or comparing models means changing the model name, not adding credentials. I would configure a fallback model at the gateway, so an outage at one provider does not block drafts. Every draft still goes through HR approval, so a fallback model's tone is not a risk. The gateway's spend tracking shows the cost per draft over time.

Postgres is the source of truth. The hire_tasks table shows each task's status, attempt count, last error and external references. HR can view it through a simple dashboard, a Google Sheets sync, or the manager's Slack summary when onboarding completes. n8n execution logs are for engineers, not HR. I would alert on any task in the failed state. I would also alert on tasks stuck in progress longer than expected, unsigned documents close to the start date, welcome drafts awaiting approval near day one, and an account not activated on the start date. These rules come from a scheduled check against Postgres, not only from node failures.

Because the hire ID does not include the start date, a corrected submission maps to the same record. The orchestrator spots the changed field and marks the date-dependent tasks for redo: meetings, the welcome draft and approval, the day-one DM and the activation schedule. Accounts and e-sign are left as they are. Meetings uses the stored event IDs to move the existing events instead of creating new ones. A welcome message that was already sent cannot be recalled, so HR is asked to approve a short correction. Activation reads the start date from Postgres at run time, so it picks up the new date automatically.

A Switch node is fine when there are a few stable roles. It is visible and easy to debug. But group and channel mappings change often, and each change would mean editing and redeploying the workflow. At larger scale, I would move the mapping into a Postgres table or a Google Sheet that HR or IT can maintain. The accounts sub-workflow would look up the role and department, with a Switch only for unknown roles, which go to a safe default with minimum access and an alert. That also creates an audit trail of who changed which access rule, which matters because this mapping decides what access people get.

n8n saves execution data by default, which helps debugging but keeps personal data in node inputs and outputs. I would turn on execution pruning with a defined maximum age. I would consider not saving successful executions for the most sensitive workflows, while keeping failed ones long enough to investigate. Access to view executions is limited to the operations team. Postgres task status, not execution logs, is the long-term record, so pruning loses nothing important. Sensitive values such as document links are kept out of fields that get logged where possible, and the retention periods are agreed with HR and legal, not chosen arbitrarily.

Waiting executions resume on the current saved version of the workflow. A careless edit to the e-sign sub-workflow could therefore break envelopes that are already waiting. I keep sub-workflow inputs and outputs as a stable contract: same field names, with new fields optional. I make backward-compatible changes, or create a new sub-workflow version that new hires call while old ones finish on the old version. Changes go through a test environment first, and workflows are exported to source control so we can review differences and roll back. Before deploying, I check Postgres for hires in progress to understand what a change could affect.

A template is deterministic, cheap and cannot get facts wrong. For many companies it is enough. AI helps when messages should vary by role, team and meeting plan, so they read naturally without HR maintaining many templates. The cost is that the output must be checked, which is why the prompt includes only the needed facts and HR approves every draft. A reasonable middle ground is to generate only the personalised paragraph with AI and keep dates and meeting times in template slots filled from Postgres. That removes most of the fact risk. I would decide based on whether HR values the personalisation enough to review each draft.

A separate cancellation workflow, triggered by HR, reads the hire's tasks from Postgres and reverses only what exists, using the stored external IDs. It deletes or keeps suspended the Workspace user, removes the Slack invite, cancels the calendar events, voids the e-sign envelope through the provider's API, and stops any waiting executions. It also blocks pending sends: the approval and DM steps check the hire's overall status before sending, so a cancelled hire never gets a welcome. Each reversal is recorded per task, so the cancellation itself can be retried safely. Anything that cannot be undone automatically is flagged for HR to handle manually.

The form is quick to build, needs no access to an HR system, and limits the input to exactly the fields needed. It suits a company without a mature HRIS or with a simple process. The trade-off is that HR types data twice and the system is only as accurate as that typing. That is why validation matters. If the company has an HRIS with webhooks or an API, triggering from the 'hire accepted' event removes re-typing and gives a natural hire ID. The rest of the design stays the same, because only the trigger and field mapping change. The orchestrator and sub-workflows do not depend on where the data came from.

1. AA unique key on hire_id with INSERT ... ON CONFLICT DO UPDATECorrect answer
2. BCreating a new row and deleting old ones each night
3. CStoring records in workflow static data
4. DA Code node that checks the execution ID

Why: A unique key plus an upsert guarantees at the database level that one hire has one row, even when two submissions arrive at the same time.

1. AA deterministic value such as an HR reference or a normalised personal emailCorrect answer
2. BThe submission timestamp
3. CA random UUID generated for each form submission
4. DThe n8n execution ID

Why: Only a deterministic ID maps a resubmission to the same hire; random, execution-based or time-based IDs create duplicates.

1. AAfter the e-sign webhook arrives
2. BOnly after HR approves it through the Wait-for-form approvalCorrect answer
3. COn the start date whatever HR decides
4. DAs soon as the AI Agent returns a draft

Why: The rule is that no unapproved message is sent, so sending is gated on the approval form.

1. ADelay the whole orchestrator until the start date
2. BShare the password only on day one
3. CCreate the user active and ask the hire not to log in
4. DCreate the account suspended or without services, and activate it with a scheduled job on the start dateCorrect answer

Why: Separating creation from activation lets the work email exist early while access begins only on the start date.

1. ARetry-on-fail on the Form Trigger
2. BDeleting the failed execution
3. Cn8n automatically skips nodes that succeeded before
4. DPer-task status in Postgres, checked before each task runsCorrect answer

Why: Stored task status lets each step see it is already done and skip itself.

1. ALoop Over Items
2. BHTTP Request
3. CExecute WorkflowCorrect answer
4. DMerge

Why: Execute Workflow runs another n8n workflow as a sub-workflow, passes it items and can wait for its completion to use the returned data.

1. ASchedule Trigger
2. BChat Trigger
3. CWebhook node
4. DExecute Workflow Trigger (When Executed by Another Workflow)Correct answer

Why: A sub-workflow called through Execute Workflow starts with the Execute Workflow Trigger, which receives the items passed by the parent workflow.

1. ATurn off the Execute Workflow node's 'wait for sub-workflow completion' optionCorrect answer
2. BAdd a Wait node with a long timer in the orchestrator
3. CUse a Merge node to wait for the signed status
4. DSet retry-on-fail with a long wait between tries

Why: Without waiting for completion, the orchestrator continues straight away while the sub-workflow runs and waits on its own.

1. AMerge
2. BSwitchCorrect answer
3. CLoop Over Items
4. DWait

Why: Switch sends items to different outputs based on a value such as role.

1. AThe Form Trigger has an on-error field
2. BQueue mode sends failures to Redis for alerts
3. CEach node gets an extra output wired to Slack
4. DEach workflow's settings name an error workflow that begins with an Error TriggerCorrect answer

Why: In n8n, a workflow's settings specify an error workflow, which starts with the Error Trigger node.

1. AThe manager named in the form does not exist
2. BA required field is missing from the form
3. CGoogle Workspace returns a temporary 503 or rate-limit errorCorrect answer
4. DThe Slack credential has been revoked

Why: Retries help with transient errors; bad data and broken credentials need a human through the error workflow.

1. AFirst name, role, team, start date and meeting timesCorrect answer
2. BSigned offer document text
3. CWork email password and Slack token
4. DFull form payload including personal email and location

Why: The prompt contains only the facts the message needs, to keep data exposure and error sources small.

1. AAlways book in UTC and let the hire convert
2. BStore times as plain text like '10am'
3. CUse the n8n server's default time zone
4. DMap location to an IANA time zone and pass it explicitly to Google CalendarCorrect answer

Why: An explicit IANA zone handles daylight saving and avoids depending on the server's setting.

1. AOnly the word 'failed'
2. BThe decrypted credential that failed
3. CThe full item payload with personal email and location
4. DHire ID, failed node and execution linkCorrect answer

Why: This gives enough context to act without pushing personal data or secrets into Slack.

1. AOnly that the HTTP method is POST
2. BThat the AI Agent agrees
3. CNothing, because the URL is secret
4. DThat it is verified, the envelope ID matches the stored hire, and the event means completedCorrect answer

Why: Verification and matching the envelope ID stop forged, mismatched or 'viewed' events from setting the signed status.

1. AIF nodes ignore JSON
2. BIF nodes cannot read Postgres results
3. CBoth executions may read 'not found' before either writes; only a database constraint or atomic claim prevents itCorrect answer
4. DIF nodes run only in queue mode

Why: A check followed by a separate write is a race; atomic database operations close the gap.

1. AA Webhook trigger exposed to Vercel
2. BA separate provider API key per model stored in n8n
3. CAn OpenAI-compatible chat model sub-node with base URL https://ai-gateway.vercel.sh/v1 and an AI Gateway API keyCorrect answer
4. DA Code node that loads a local model

Why: The gateway exposes an OpenAI-compatible API, so one AI Gateway credential on the chat model sub-node reaches many providers by model name, with no provider keys kept in n8n.

1. AA Code node that loops and polls every second
2. BA Wait node that resumes on the provider's webhook, in a sub-workflow the orchestrator does not wait onCorrect answer
3. CRetry-on-fail set to a very high count
4. DA Schedule Trigger every minute in the orchestrator

Why: The Wait node can resume on an incoming webhook without busy polling. Running it independently keeps the parent execution from staying open for days.

1. A$node.url
2. B$json.webhookUrl
3. C$execution.resumeUrlCorrect answer
4. D$workflow.id

Why: $execution.resumeUrl is the execution-specific URL that resumes a waiting execution.

1. Ahttps://anthropic.com/claude-sonnet-4.5
2. Bclaude-sonnet-4.5 with an Anthropic API key
3. Canthropic/claude-sonnet-4.5Correct answer
4. Dai-gateway:claude

Why: AI Gateway uses provider/model names such as anthropic/claude-sonnet-4.5 on one OpenAI-compatible endpoint.

1. AIn the Postgres hires table
2. BIn an n8n credential for each provider
3. CNot in n8n; n8n holds only the AI Gateway API keyCorrect answer
4. DIn the AI Agent's system prompt

Why: The gateway design keeps provider keys out of n8n and uses one AI Gateway key.

1. AIt removes the need for HR approval
2. BIt supports fallbacks and spend tracking across providers through one credentialCorrect answer
3. CIt stores the hire's personal data for later prompts
4. DIt makes model output deterministic

Why: The gateway provides fallbacks, spend tracking and access to many providers with one key; it does not make output safe or deterministic.

1. ARedisCorrect answer
2. BKafka
3. CA vector store
4. DGoogle Sheets

Why: n8n queue mode uses Redis as the message broker between the main instance and workers.

1. ARemoving duplicate hires
2. BCombining the account and meeting results into one item for the AI AgentCorrect answer
3. CJoining Postgres tables
4. DSending data to several sub-workflows at once

Why: Merge combines data from separate branches so the AI Agent gets the work email and the meeting times together.

1. ALoop Over ItemsCorrect answer
2. BIF
3. CSet/Edit Fields
4. DChat Trigger

Why: Loop Over Items processes items in batches, which helps control pressure on Google and Slack APIs.

1. AInside Code node source
2. BIn plain text inside workflow JSON
3. CEncrypted, and referenced by nodesCorrect answer
4. DOnly in environment variables on each worker

Why: n8n encrypts stored credentials, and nodes reference them without exposing the secrets.

1. AThe execution resumes, so the workflow can check status and send a reminderCorrect answer
2. Bn8n retries the e-sign request automatically
3. CThe error workflow always fires
4. DThe execution is deleted

Why: With a time limit, the Wait node resumes after the limit, which lets the workflow take the reminder path.

1. ARetries pause the workflow for days
2. BRetries are not supported on app nodes
3. CA timed-out call may have succeeded, so a blind retry can create a duplicateCorrect answer
4. DRetries leak credentials

Why: Non-idempotent creates need a lookup or idempotency guard so a retry cannot duplicate the account.

1. APut the start date in the AI prompt
2. BUse retry-on-fail with a long wait
3. CSend it immediately and ask Slack to delay it
4. DUse a Wait node set to resume at a specified time, or a scheduled workflow that reads start dates from PostgresCorrect answer

Why: Waiting until a set time or scheduling from stored dates delivers the DM on day one.

1. ADeleting and recreating the sub-workflow
2. BChanging its trigger type
3. CRenaming the fields other workflows expect
4. DA backward-compatible change that keeps the input and output fields stableCorrect answer

Why: Waiting executions resume on the current version, so the input/output contract must stay compatible.

1. AGo or Rust
2. BOnly JSONata
3. CJavaScript or PythonCorrect answer
4. DOnly SQL

Why: The Code node supports JavaScript and Python.

1. AOnly as a Vercel function
2. BOnly n8n Cloud
3. CSelf-hosted or n8n CloudCorrect answer
4. DOnly a desktop app

Why: n8n is fair-code and can be self-hosted or used on n8n Cloud.

1. AEmbeddings
2. BMerge
3. CSchedule Trigger
4. DInformation ExtractorCorrect answer

Why: The Information Extractor node turns unstructured text into structured fields.