# Employee Onboarding Access Workflow

Design employee onboarding across HR, identity, equipment, accounts, training, approvals, and evidence without granting unsafe automatic access.

## Prompt

You are a senior workflow automation designer. Your task is to design an employee onboarding workflow that coordinates administrative preparation while preserving identity, security, privacy, and authorization controls.

Design the workflow so it can be implemented in Zapier, Make, n8n, a native integration, or custom code. Do not pretend that you have connected to, configured, tested, or deployed any system. Do not invent field names, API capabilities, permissions, prices, limits, credentials, business rules, or approval authority.

USER INPUT
Authorized onboarding trigger: {{authorized_trigger}}
HR, identity, IT, payroll, training, and communication systems: {{tools}}
Required employee fields: {{employee_fields}}
Role, department, manager, location, and start date: {{role_context}}
Approved access packages and role rules: {{access_rules}}
Equipment and logistics rules: {{equipment_rules}}
Training and policy requirements: {{training_rules}}
Owners and service levels: {{owners_sla}}
Exceptions for contractors, interns, remote staff, or transfers: {{exceptions}}
Offboarding or cancellation linkage: {{cancellation_rules}}

DESIGN METHOD
1. Verify that onboarding begins only from an authorized HR record or approved request.
2. Validate identity, legal name, preferred name, start date, employment type, manager, location, and role.
3. Separate preboarding tasks from account provisioning and first-day actions.
4. Map approved role packages to requested systems and permissions.
5. Require named approval for privileged, financial, production, customer-data, or administrator access.
6. Prevent account creation before the permitted date and handle changed or cancelled starts.
7. Coordinate equipment, workspace, training, policy acknowledgement, payroll preparation, and manager tasks.
8. Record fulfillment evidence and exceptions for every item.
9. Define reminders, escalation, manual fallback, and a secure handoff.
10. Link the design to role changes and offboarding so access does not remain unmanaged.

REQUIRED OUTPUT
A. Authorized trigger and eligibility
B. Required employee data and validation
C. Preboarding, first-day, and follow-up timeline
D. Role-to-access matrix
E. Approval gates and segregation of duties
F. Equipment, training, and administrative task flow
G. Changed, delayed, and cancelled start handling
H. Evidence, audit, and privacy controls
I. Failure and manual fallback
J. Test cases
K. Implementation checklist

CORE RELIABILITY RULES
1. Separate confirmed requirements from assumptions and unresolved questions.
2. Define one precise trigger and the conditions that should block false or duplicate runs.
3. Identify the system of record for every important field.
4. Map data explicitly between source and destination fields.
5. Validate required fields before taking downstream actions.
6. Use a stable unique identifier or idempotency key to prevent duplicate records and repeated messages.
7. Add human approval before external messages, publishing, payments, deletion, permission changes, or other difficult-to-reverse actions.
8. Define retries, timeouts, error logging, alert ownership, and a manual fallback.
9. Minimize movement and storage of personal or sensitive data.
10. Keep secrets in the automation platform's secure credential manager. Never request real API keys, passwords, access tokens, or webhook secrets.
11. Include test cases for the happy path, missing data, duplicates, invalid data, unavailable services, permission failures, and partial completion.
12. End with a clear list of items that require human confirmation before implementation.
13. Never infer access rights from job title alone; use an approved role-to-access policy.
14. Never send passwords through email or chat, and never include sensitive HR data in broad notifications.

## Best for

HR, IT, security, and operations teams coordinating repeatable employee or contractor onboarding across several systems.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Provide the authorized HR trigger, systems, role context, access policy, and owners.
- Define standard versus privileged access and required approvers.
- Review personal-data movement and account timing with HR, IT, and Security.
- Test delayed, changed, cancelled, duplicate, contractor, and privileged-access cases.

## Customization tips

- Create role packages from an approved access matrix rather than free-text requests.
- Use employee IDs instead of names as cross-system identifiers.
- Add equipment shipping and return rules for remote workers.
- Link onboarding records to role-change and offboarding workflows.

## Example input

Workday contains approved hires. Onboarding should create IT and Facilities tasks, prepare a laptop, enroll required training, create a Google Workspace account one business day before the start date, and request manager approval for GitHub and production tools. Payroll remains manual. Cancelled starts must stop all pending actions and create a review task for anything already completed.

## Example output

Trigger:
Approved Workday hire with complete manager, role, location, employment type, and start date.

Timeline:
Immediately after approval: create IT, Facilities, and manager tasks.
Before start date: prepare equipment and training assignments.
One business day before start: create the standard Google Workspace account if the hire remains active.
Privileged access: create approval requests for GitHub and production tools.
Payroll: create a manual preparation task only.

Cancelled start:
Stop pending provisioning.
Disable or quarantine accounts already created according to approved policy.
Create a review task listing completed assets and actions.
Notify only authorized owners using employee ID and minimal necessary information.