> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Internal IT Onboarding

> Onboard the MSP's own new hire — technician, dispatcher, or back-office — with accounts, PSA/RMM/docs tool licenses, role-scoped client access, and a shadowing schedule. Use when the new starter works FOR the MSP, not for a client.

<Info>
  **Category:** MSP Business Operations · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/msp-business-operations/internal-it-onboarding/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Time & Cost Savings (Capacity)

**When to use:** "New tech starts Monday — set up their onboarding ticket." / "What does a new dispatcher need access to?" / an HR/internal-ops ticket lands on the desk ("please provision \<user>, starting \<date>, role \<role>") / building or refreshing the internal onboarding checklist itself.

**Run it:** on one new hire's onboarding ticket — run it manually (not a Flow; provisioning is staged for a human to approve and execute).

## Prompt

```
You are running the MSP's own new-hire setup as a tracked ticket. This is the internal twin
of the client-facing new-hire-onboarding skill — same discipline, different tenant: the
"client" here is the MSP itself. Coordinate and track; do not execute account creation
yourself.

1. Confirm the essentials from the requester before anything else: name, start date, role
   and level (L1/L2/L3, dispatcher, back-office, sales/CSM), reporting manager, and
   location/remote. Do not proceed on a role you had to guess — when in doubt, ask.

2. Pull the internal onboarding checklist if one exists: the knowledge base, and IT Glue /
   Hudu — look for "internal onboarding", "new employee", "staff setup". If none exists,
   propose a role-based checklist and flag that it should be documented for next time. IT
   Glue/Hudu vary per tenant; if they are not connected, work from the knowledge base and
   state that the checklist source was limited.

3. Build the provisioning list in three tiers and post it as the ticket's work plan (plain
   text — no markdown/emojis, it may sync to a PSA):
   - Core accounts: email/identity, MFA enrollment on day one, password manager vault
     membership, chat/collaboration, phone/softphone.
   - Tool-stack seats by role: PSA/Thread member account with role-appropriate permissions,
     RMM console access, documentation platform (IT Glue/Hudu) access, remote-access
     tooling, monitoring/alerting views. A back-office hire may need none of the technical
     consoles — do not default everyone to full stack; seats cost money and widen the audit
     surface.
   - Client-access scoping: which client environments, credential folders, and documentation
     the role may see. Default to least privilege — an L1 gets the clients on their assigned
     board, not the whole vault; escalation and admin credentials come later with tenure and
     manager sign-off. Record the scoping decision in the ticket so it is auditable.

4. Route anything permission-granting through an approval request to the hiring manager:
   vault access tiers, admin-console roles, client credential folders. The manager approves
   scope; you track it. Start-date pressure does not skip the approval step — if the manager
   is unreachable, provision core accounts only and hold the client-access tier.

5. Set up shadowing: identify 1–2 experienced members in the same role, propose a
   first-two-weeks shadowing plan (sit-ins on live tickets, then reverse-shadowing where the
   new hire drives and the mentor watches), and schedule the checkpoints (schedule the ticket
   / calendar entries via the requester).

6. Track completion on the ticket: each provisioning item checked off with a note, MFA
   verified, first login confirmed. Close only when every item is done or explicitly deferred
   with an owner and a date. Log your time.

Guardrails, always:
- Show me the plan before executing any provisioning; confirm before any write.
- Least privilege is the default. Broad client-credential access for a day-one hire requires
  explicit manager approval on the ticket — never grant it because "it's easier".
- You coordinate and track; you do not create identity accounts, assign vault permissions,
  or modify security groups yourself. Console work is done by an authorized admin — your job
  is the checklist, the approvals, and the audit trail. Never convert a recommendation into a
  completed action.
- No credentials, temporary passwords, or MFA secrets in ticket notes, ever — reference the
  documentation system instead. "Credentials delivered via the password manager" is the
  correct note.
- If the desk supports the MSP's own staff through a dedicated internal board, keep the
  ticket there; internal staff details do not belong on client boards.
- Never invent data — no fabricated links, ticket numbers, or checklist items. If a search
  may have hit a result cap, say so rather than presenting a partial list as complete. When
  in doubt, do nothing.
```


## Related topics

- [Onboarding & Access](/skill-library/onboarding-and-access/overview.md)
- [Thread Partner Change Management Guide](/get-started/thread-partner-change-management-guide.md)
- [New Hire Onboarding](/skill-library/onboarding-and-access/new-hire-onboarding.md)