Employee Onboarding Automation
Employee onboarding automation prepares repeatable welcome information, checklists and coordinator handoffs from an approved employee record. A useful starting point is a reviewed onboarding pack that states the role, applicable policy version, assigned tasks and unresolved details.
In this AI Flowi Workflow proposal, HR approves the source row and a coordinator checks the generated pack. Payroll changes, account provisioning and employment advice are outside the configuration.
Define the onboarding pack’s boundaries
A pack is preparation material, not proof that onboarding tasks have happened. Separate requested tasks from completed tasks and keep the actual completion record in the process your team already uses. A generated line saying “equipment requested” should never be treated as confirmation that equipment was supplied.
Keep general policy content out of individual employee rows. The row supplies authorised facts such as the employee reference, role, start date and coordinator. A separate approved checklist supplies role-specific steps. An applicable policy source explains the steps without letting a model invent conditions or obligations.
| Approved input | Pack section | Blocker to resolve |
|---|---|---|
| Employee reference and role | Identity label and selected role checklist. | Ambiguous role or wrong source row. |
| Confirmed start date | Coordinator planning notes. | Unconfirmed date remains marked for review. |
| Checklist revision | Task descriptions and assigned department. | Missing task responsibility. |
| Policy passage and revision | Source-backed welcome explanations. | Contradictory or inapplicable policy. |
| Coordinator approval | Reviewed draft ready for manual handover. | Generated draft alone cannot supply approval. |
Prepare the accounts and an isolated trial
Prepare a synthetic employee row, the approved role checklist and an HR reviewer in the workflow workspace; authorise the isolated Sheets and Docs destinations through the Google access reference and arrange separately charged embedding and drafting services with credentials for your chosen providers through the model-access reference.
A Notion draft is optional. If you choose it, use your own Notion account and integration credential with access to the test database or page. Start with a test destination containing no employee records. See Notion component setup and connection documentation for the underlying access requirements.
Configure the coordinator’s draft
example configuration, not a recorded test
This onboarding combination is documented in the catalogue; not production-tested by Ai Flowi.
- Read Range: select the authorised connection in
google_account. Pointspreadsheet_idat the isolated onboarding workbook. Restrictrange_nameto the HR-approved employee row. Check the returnedvaluesagainst its column headings before drafting the pack. - Knowledge Base: use the policy retrieval instructions for the employee role and location.
- Parser: follow the Parser reference separately for the employee row and policy extract.
- Prompt Template: place literal onboarding instructions in
template, followed by the row HR checked, its selected checklist and the applicable policy extracts. The resultingprompthas type Message. Source assembly is manual here; consult the formatting reference before attempting variable substitution. - OpenAI and Structured Output: obtain the model connection through the provider setup reference; attach its LanguageModel output to
model. Pass the manually assembled pack prompt throughinput_value. Name this draft contractonboarding_pack_draftinschema_name. Fill the table editor foroutput_schemawith pack title, pack text, policy references and unresolved items. Insystem_prompt, forbid invented start dates and claims that requested tasks have been completed. - Review the structured draft against the original row. A coordinator approves the wording and unresolved items before the document-writing stage.
Choose a document or Notion draft
Use the shared JSON-to-Doc preparation for an accepted onboarding pack.
Here the proposed title field is pack_title and the content field is pack_text: carry the employee reference and checklist revision into the title, and include requested tasks with their responsible departments in the text. Keep an unconfirmed start date in the coordinator’s issue list rather than turning it into welcome instructions.
For an optional Notion draft, Create Page lists notion_secret, database_id and Message-compatible properties_json. Build the properties payload only after confirming the destination database’s fields. The export does not supply a full properties schema. Inspect api_run_model before taking the created page identifier into another step.
Add Content to Page uses notion_secret, block_id and markdown_text; its description specifies converting markdown into blocks and appending them. Check the created page reference manually before using it as block_id. Re-running an append can repeat text, so inspect the target before retrying an uncertain write.
Reconcile a changed start date before handover
In a synthetic trial, the approved employee row contains a confirmed start date, while an older welcome draft contains the previous date. The coordinator should identify the employee reference and row revision, then prepare a replacement draft from that checked row. Do not change the policy revision simply because the date changed; policy applicability is a separate decision.
During source preparation, preserve employee reference, role, start-date status and coordinator from the row, and keep checklist revision and policy passage with their separate sources. Losing the confirmed-versus-proposed date label can turn a planning suggestion into an apparent commitment. A policy extract must retain the role or location restriction that determines who it applies to.
The revised pack lists requested tasks and their responsible departments. The coordinator checks the document title against the intended employee and tells the receiving department which draft supersedes the earlier one. Equipment delivery and account activation remain separate completion records; replacing a welcome document cannot establish either event.
Keep replacement packs distinct from completed tasks
When a coordinator accepts a replacement, retain the previous draft reference and explain the changed source: an amended employee row, a revised checklist or a newly applicable policy. A start-date correction should be visible to departments arranging equipment, while unchanged tasks retain their existing completion status. Ask the coordinator to reconcile those records before handover. Generating another pack cannot cancel an earlier request, reset a completed task or tell a receiving department which version to follow. Those are explicit coordination decisions, recorded outside the generated text.
How do I check the onboarding pack and partial failures?
- Leave the start date unconfirmed in a synthetic row. The pack should ask the coordinator to resolve it.
- Use a role with no approved checklist. Check that generic model knowledge does not become a new policy.
- Supply a stale policy passage. The reviewer should reject it before document creation.
- Create a draft with an unavailable destination. Inspect both the node error and the target before another attempt.
- Repeat an accepted request. Verify whether a second document or repeated Notion content appears; this proposal has no deduplication step.
Understand the evidence boundary
The form-submission document example reports 42/42 passes, accepting the conversion of Windows line endings into LF. Its checks address form validation and document read-back; they exclude this role checklist, policy lookup and Notion branch. That page also covers recovery when creation succeeds but the first content write fails: the coordinator must inspect the destination rather than assume a complete welcome pack exists.
Use a simpler checklist if the coordinator only needs a stable list of tasks. This model-assisted design is unsuitable for automatic employment changes, permissions provisioning or interpreting policy exceptions. Access controls, employee-data retention and approval recording must be set by your team; generated review fields do not enforce them.
Usage and related process design
Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.
Count each selected output branch and any repeated attempts from actual history. The HR workflow map explains departmental handoffs; recruitment administration covers earlier application records. Consult the catalogue reference and use cases for component and recipe scope.
By Ai Flowi · Onboarding guidance by Ai Flowi · Publication date
Official source: Notion API documentation