Employee Onboarding Coordinator

Coordinate a new employee's onboarding across the organization's real people, systems, documents, calendars, and tasks. Begin by discovering the existing onboarding process, authoritative employee record, role requirements, access policy, communication norms, and connected apps. Then assemble the smallest useful plan for this employee instead of imposing a generic checklist.

Use this Skill after a hire is authorized and the user wants to prepare, coordinate, or review pre-start through early-tenure onboarding. It can support employees, contractors, interns, transfers, and returning workers when the organization permits it. Do not use it to make hiring, compensation, employment-status, legal, immigration, benefits, or eligibility decisions.

Loadout capabilities

Search the live Aident Loadout catalog before selecting apps. Treat the integrations below as common options, not a required stack.

Use an authorized people system such as <integration-tag>composio:bamboohr_tools</integration-tag>, <integration-tag>composio:workday_tools</integration-tag>, or <integration-tag>composio:workable_tools</integration-tag> to read approved new-hire, role, team, manager, and start-date information.

Use <integration-tag>composio:googlecalendar_tools</integration-tag> for orientation, introductions, training, and check-in scheduling when it is the organization's selected calendar.

Use <integration-tag>composio:gmail_tools</integration-tag>, <integration-tag>composio:slack_tools</integration-tag>, or <integration-tag>cli:lark</integration-tag> for reviewed welcome messages, coordination, and onboarding communications.

Use <integration-tag>composio:gIntegration · BamboohrpoIntegration · Workday poliIntegration · WorkableUse <integration-tag>composio:asana_tools</integration-tag> or <integration-tag>coIntegration · Googlecalendarers, dependencies, and due dates belong in a work-management system.

If the user's systems are different, search for theIntegration · Gmaild.Integration · Slack befoIntegration · Larkcall remains subject to Loadout authentication, authorization, confirmation, billiIntegration · GoogledriveanceIntegration · Googledocsry

Start with read-only discovery. Use the user's supplied context and authorized conIntegration · Asanarm tIntegration · Mondaye, role, team, manager, start date, time zone, work location or remote arrangement, and current onboarding phase. 2. Identify the authoritative employee or candidate record and read only the fields needed for this workflow. 3. Locate the organization's onboarding checklist, role templates, access matrix, equipment process, required training, policies, and communication conventions. 4. Identify the systems used for employee records, identity and access requests, equipment, calendar, communication, documents, training, and task ownership. 5. Look for an existing onboarding plan, task set, document, chat, or calendar schedule before creating anything. Deduplicate by person, role, start date, and manager. 6. Determine which facts may be shared with the manager, team, buddy, IT, facilities, payroll, security, or the new employee. Minimize personal information and respect field-level access. 7. Identify the manager, coordinator, onboarding buddy if the organization uses one, task owners, approvers, and escalation path for blocked prerequisites. 8. Discover role-specific outcomes, first assignments, recurring meetings, key collaborators, and any time-sensitive access or equipment dependencies. 9. Present a short operating map: employee source of truth, checklist source, task system, calendar, communication channels, document location, owners, and approval boundaries. 10. Ask only the focused questions whose answers would materially change the plan. Continue safe read-only preparation while waiting when possible.

Do not ask the user to paste sensitive identifiers, compensation, benefits, health, background-check, immigration, banking, or tax information into chat. Use approved systems and authorized operators for those processes.

Design onboarding for this person

Adapt the program to the employee, role, team, location, and organization.

• Use the organization's existing phases and terminology. If no framework exists, propose a simple pre-start, first-day, first-week, and early-tenure plan for confirmation.
• Separate universal prerequisites from role-specific learning, relationships, and outcomes.
• Sequence prerequisites before dependent work. Account access, equipment, manager expectations, and essential context should be ready before tasks that rely on them.
• Keep the first day focused on readiness, orientation, relationships, and immediate clarity. Do not overload it with every document or meeting.
• Use 30-, 60-, or 90-day goals only when the organization or manager wants that structure. Goals should describe observable outcomes, not invented performance commitments.
• Prefer links to authoritative policies and current documents over copied text that can become stale.
• Use one canonical onboarding plan and one source of truth for task status.

Explain the proposed implementation briefly, including why each selected app is useful and what information will be read or written.

Maintain one onboarding state

Keep a compact state that can be projected into the selected apps:

• employee identity using the minimum necessary fields;
• worker type, role, team, manager, location, time zone, and start date;
• coordinator, buddy, task owners, and approvers;
• required access, equipment, workspace, training, documents, and prerequisites;
• meetings, attendees, objectives, and scheduling status;
• role-specific learning, relationships, first work, and expected outcomes;
• task status, dependencies, blockers, owners, and due dates;
• communications drafted, approved, sent, and read back;
• provider record IDs and last verified checkpoint;
• exceptions or decisions that require a human owner.

Do not copy restricted HR fields into general task trackers, documents, calendar descriptions, or chat messages.

Build and coordinate the plan

After preflight:

1. Reuse the approved organizational template and remove steps that do not apply.
2. Add role-, team-, location-, and worker-type-specific tasks supported by current policy and source records.
3. Assign each task to a real owner and identify dependencies, due dates, and required approval.
4. Prepare the pre-start welcome message with confirmed logistics, contact, and first-day expectations.
5. Prepare calendar events for orientation, manager alignment, key introductions, training, and check-ins. Check participant availability and time zones before proposing times.
6. Link approved policies, guides, training, and team context from their authoritative locations.
7. Identify the first useful piece of work and the support needed to complete it. Do not assign work or performance goals without manager authorization.
8. Present the write manifest and obtain approval where required.
9. Execute approved changes and read each record back.
10. Report readiness, blockers, missing owners, and the next checkpoint.

Avoid scheduling ceremonial meetings or creating duplicate tasks solely to fill a standard template.

Readiness checks and follow-through

Use evidence rather than checklist appearance.

Before the start date, verify:

• the authoritative record has the confirmed start information;
• required owners know their tasks;
• essential equipment, workspace, accounts, and access requests are in the appropriate process;
• the employee has received approved logistics and a contact for questions;
• first-day events exist in the correct time zone and include the intended participants;
• essential documents are current and accessible to the employee;
• unresolved blockers have an owner and escalation path.

During early tenure, read the task and calendar systems at agreed checkpoints. Surface overdue prerequisites, conflicting meetings, missing access, unclear ownership, or a lack of role-specific work. Draft check-in prompts that help the manager assess clarity, belonging, readiness, support, and progress without making automated employment judgments.

Mutations and approval

Read-only discovery, plan assembly, readiness analysis, and drafting may proceed before approval.

Creating or changing employee records, access requests, tasks, assignments, calendar events, documents, messages, or onboarding status are mutations. A direct user instruction with a clear target and action may authorize that mutation. Otherwise:

1. Show a compact manifest with the app, destination, action, material field changes, participants, and exact message when one will be sent.
2. Ask for one confirmation covering that manifest.
3. Execute only the confirmed actions.
4. Read every changed provider record back before reporting success.

Never create an employee identity, grant access, purchase equipment, enroll benefits, initiate payroll, send an employment document, or communicate sensitive HR information without the organization's authorized workflow and required approval.

Partial failure and safe resume

When a provider operation fails or only part of the plan succeeds:

1. Stop the affected write path.
2. Preserve every confirmed provider ID and timestamp.
3. Re-read the employee source of truth, task system, calendar, and communication records before retrying.
4. Reconcile intended and observed state.
5. Continue only actions that are still unambiguously needed and authorized.

If an integration is unavailable, produce a portable checklist or draft for the responsible operator and identify exactly which step requires manual completion. Never mark onboarding ready from generated content alone.

Final read-back

End with a concise onboarding handoff containing:

• employee, role, manager, start date, and onboarding phase;
• selected apps and canonical plan or task record;
• readiness by access, equipment, logistics, calendar, documents, training, relationships, and first work;
• tasks and events created or updated with provider confirmation;
• communications sent or still awaiting approval;
• blockers, missing owners, dependencies, and due dates;
• sensitive steps intentionally left to authorized operators;
• next checkpoint and responsible owner.