Jira Onboarding Checklist: 30 Tasks by Phase and Role
TL;DR: This page is the complete Jira onboarding checklist — 30 tasks broken into Day 1, Week 1, Month 1, and the 90-day mark, grouped by department (IT, HR, Manager, Security) and role (Engineering, Sales, HR). Copy the table below. No signup required. PPLX Software builds TeamOps, a Forge-native Jira app that automates this checklist — but the checklist works without it too.
A Jira onboarding checklist is the full list of tasks a new hire needs to complete — and that IT, HR, and their manager need to complete for them — in the first 90 days, tracked inside Jira. This guide gives you that checklist, plus the Jira-specific setup steps that determine whether it stays usable as you scale.
The common failure mode is building this as a flat list of sub-tasks under a single parent issue. That works for five people. At twenty hires a year, you end up with 600 open sub-tasks on a board nobody wants to open. The structure below avoids that.
The complete Jira onboarding checklist
30 tasks organized by phase and department. The Jira-specific note column explains where the gotchas are.
| # | Phase | Department | Task | Jira-specific note |
|---|---|---|---|---|
| 1 | Day 1 | IT | Create the onboarding Epic | Name it "Onboarding – [Name]". Set start = hire date, due = 90-day mark. Use an Epic so sub-tasks don't spill into sprint boards. |
| 2 | Day 1 | IT | Provision laptop and ship to hire address | Create a sub-task assigned to IT. Add a due date 5 business days before start — shipping lead time catches admins who create this task on the first day. |
| 3 | Day 1 | IT | Create Atlassian account and add to Jira | Add to relevant Jira projects with Developer permission — not Admin. New admins accidentally change workflow configurations on their first day more often than you'd expect. |
| 4 | Day 1 | IT | Provision VPN credentials | Do NOT put credentials in Jira comments — all project members can read them. Use a secrets manager (1Password, Keeper) and add the link to the Jira task instead. |
| 5 | Day 1 | Security | Create badge and building access request | Assign to Facilities or Security as a separate Component so their tasks are filtered without affecting IT's view. |
| 6 | Day 1 | IT | Set new hire's Jira notification preferences | Default Jira notifications fire on every comment and transition. Walk new hires through Project Settings → Notifications → set to "Mentioned" only for the first week, or they'll disable email notifications entirely within 48 hours. |
| 7 | Day 1 | HR | I-9 / right-to-work documentation collected | Track completion in a Jira task, but store the actual documents in your HRIS or Confluence's restricted HR space — not in Jira attachments visible to all project members. |
| 8 | Day 1 | HR | Benefits enrollment form sent | Set the sub-task due date to Day 3, not Day 1. Benefits enrollment forms take time to complete and Day 1 is overwhelming. Day 3 is a realistic deadline. |
| 9 | Day 1 | HR | Emergency contacts and policy acknowledgment | Link the Confluence policies space in the task description. Assign to HR with due = Day 2. This is the most commonly missed Day 1 task. |
| 10 | Day 1 | Manager | Welcome meeting and team introductions | Create the calendar invite separately. The Jira task is the tracking artifact, not the meeting itself. Add a Confluence meeting notes page as a linked resource. |
| 11 | Day 1 | Manager | Buddy / mentor assigned and introduced | Name the buddy in the task description. "Assign a buddy" without a specific name closes without action more than half the time. |
| 12 | Day 1 | IT | Slack workspace access and team channels added | List the required channels in the task description (e.g., #eng-general, #deploys, #on-call). Without a list, IT adds the new hire to #general and considers it done. |
| 13 | Week 1 | Engineering | Dev environment fully set up and verified | Include specific verification steps: "clone primary repo → run test suite → at least one test passes locally." Vague tasks like "set up dev environment" close without verification. |
| 14 | Week 1 | Security | Security and compliance training assigned and completed | Two separate tasks: one to assign (Day 1) and one to verify completion (Day 5). A single task marked Done when assigned means nobody checks if they actually finished it. |
| 15 | Week 1 | IT | Principle-of-least-privilege access audit | Review which Jira projects the new hire was added to. Remove any inherited from their onboarding project membership that they don't need for their role. |
| 16 | Week 1 | Manager | First sprint task assigned | Assign 1–2 low-stakes tasks from the existing backlog. The new hire should experience the full Jira workflow (pick up task → submit PR → review → close) before Week 2. This is the fastest way to find permission gaps. |
| 17 | Week 1 | Manager | Confluence knowledge-base orientation | Link the specific Confluence spaces they need: team wiki, runbooks, architecture docs. A link to the Confluence root is useless — it's a 300-page maze on Day 3. |
| 18 | Week 1 | Manager | First one-on-one completed | Schedule recurring, not ad hoc. Block the calendar on Day 1 so Week 1 logistics don't push it to Week 3. |
| 19 | Week 1 | HR | Benefits enrollment confirmed as submitted | Benefits elections have hard external deadlines (typically 30 days from hire). Create a task with a due date that matches the carrier's deadline, not an internal estimate. |
| 20 | Week 1 | IT | Password manager enrolled and master password set | Do this in Week 1, not Month 1. New hires accumulate weak passwords in the first two weeks and never migrate them later. |
| 21 | Month 1 | Manager | 30-day check-in and feedback form | This is also a signal for the onboarding process itself. Add a field in the task for notes on what was missing from the checklist so you can update the template. |
| 22 | Month 1 | IT | Jira project access promoted from Reporter to Developer | Many teams add new hires as Reporter (read + comment only) for the first 30 days. If you do this, create a task to promote them at Day 30 — otherwise it's forgotten and they can't close their own tasks for months. |
| 23 | Month 1 | Manager | First substantial project task assigned | Something with visible impact on a real sprint goal, not a cleanup task. The new hire should be able to say "I shipped X" in their first month. |
| 24 | Month 1 | Manager | Goals / OKRs documented and linked | Link to the Confluence OKR page. Vague verbal goal-setting at Month 1 check-ins never gets written down and creates misalignment at the 90-day review. |
| 25 | Month 1 | Security | Security training completion verified | Separate from Week 1 task 14. This verification task checks the training platform for completion status — not just self-reported. |
| 26 | 90-day | Manager | 90-day performance review scheduled and completed | Schedule during Week 1 so nobody's calendar is full. A 90-day review scheduled in Week 12 gets pushed to Week 14. |
| 27 | 90-day | IT | Full access audit | Enumerate every Jira project and third-party tool the new hire has access to. Remove any that weren't explicitly granted for their role — onboarding typically over-provisions access "just in case." |
| 28 | 90-day | Manager | Mentor relationship formally concluded or extended | Most buddy arrangements end around Day 60 without anyone saying so. Create a task to make it explicit. If extending, update the buddy's recurring calendar block. |
| 29 | 90-day | HR | Benefits confirmed enrolled and active | Distinct from the Month 1 submission confirmation. This verifies the carrier has processed enrollment and the new hire is actually covered. |
| 30 | 90-day | HR | Onboarding Epic closed in Jira | Transition Epic status to Done, add a "completed-YYYY-MM-DD" label, and link the 90-day review notes. The label makes it easy to query "how many onboardings completed this quarter" via Jira's issue search. |
How to structure this in Jira without a mess
The table above is the what. Here is the how — the specific Jira setup decisions that determine whether this checklist stays usable as your team grows.
Use a dedicated Onboarding project, not your engineering project
The most common mistake is creating onboarding tasks inside the team's main Jira project. Engineering workflows have statuses like "In Sprint," "Code Review," "Blocked," and "Deployed." None of those apply to "Provision laptop" or "Benefits enrollment form sent." When IT filters the board, they see 200 sprint tasks alongside their 8 onboarding tasks. Nothing gets done on time.
Create a separate project named "HR Operations" (or "People Ops" if you prefer). Set a simple 3-status workflow: To Do, In Progress, Done. All onboarding tasks live here, not in Engineering. Engineering still sees new hires added to their sprint boards — they just do not see the IT provisioning tasks cluttering their backlog.
Use Components for department ownership, not labels
Jira Components (created under Project Settings → Components) assign default owners and enable filtering by department. Add Components named IT, HR, Manager, and Security. When you create a sub-task under the onboarding Epic, set the Component to the owning department. Now IT can open the board and filter to "Component = IT" to see exactly their 8 tasks without noise from HR's tasks. Labels can do this too, but Components support default assignees, which means IT tasks get routed to the IT admin automatically rather than landing unassigned.
Set a parent Epic for each hire, not a single shared Epic
One "New Hire Onboarding" Epic shared across all hires creates an Epic with 180 sub-tasks inside it by Month 6. Create one Epic per person: "Onboarding – Jane Smith" with hire date as start date and 90-day mark as due date. You can then filter your Epic list by date range to see all active onboardings and their completion percentages in Jira's Timeline view.
Template the sub-tasks with a standard Epic template
Jira does not have native Epic templates (as of 2026). The options are:
- Jira Automation — trigger "When Epic created with label 'new-hire', create sub-tasks from list." Works, but the automation JSON is fragile when task templates change.
- A Confluence page with a copy-paste structure — low-tech but reliable. HR copies the task list and creates sub-tasks manually each time. Takes about 12 minutes per hire.
- A purpose-built onboarding tool like TeamOps — creates the full task structure automatically when you start an onboarding, keeps templates editable without breaking automation rules, and shows progress across all active onboardings in one view.
For teams hiring fewer than 2 people per month, the Confluence copy-paste approach is usually fast enough. For teams hiring 3 or more, manual task creation becomes the bottleneck.
Role-specific additions to the base checklist
The 30 tasks above apply to everyone. Role-specific tasks go on top of them.
Engineering additions (8 tasks)
- Repository access granted — specify which repos; "GitHub access" without a list means they have read access to everything but write access to nothing useful
- CI/CD pipeline orientation — walk through one deploy: branch → PR → review → merge → automated deploy. Not reading docs, actually doing it.
- Code review process documented — link to your team's PR review guide in Confluence. "We do code review" is not enough; new engineers need to know response time expectations and who has merge authority.
- On-call rotation added (if applicable) — not in Month 1, but by Month 2. Create the task at Day 1 with a due date 60 days out.
- Database access provisioned and documented — production read access, if applicable. Separate from development database access. Both should be explicitly granted and logged.
- Architecture overview session scheduled — 60-minute walk-through of the system with a senior engineer. The new hire's first context for why things are built the way they are.
- Security: SSH key added, old keys for prior employer removed from personal machine — most teams skip the second part. It matters.
- First bug fixed and shipped — a concrete, shippable task in Week 2 or 3. Not a cleanup task. Something with a ticket number and a merge commit.
Sales additions (7 tasks)
- CRM access provisioned and sandbox configured — name the CRM and the specific objects they need access to (Accounts, Contacts, Opportunities). Provisioning "CRM access" without specifics means they can log in but can't do anything useful.
- ICP (ideal customer profile) documentation reviewed — link the Confluence page. If it doesn't exist, create it before the new hire's first day.
- Sales script and objection-handling guide reviewed — again, a link. Not a meeting. The new hire reads it independently, then the first one-on-one covers questions.
- First 3 cold call or cold email shadows completed — with a senior rep. Listening is faster than reading.
- Product demo certification — complete a full demo for the hiring manager before Week 3 ends. Create the task on Day 1 with a due date so it doesn't slip.
- Quota and comp plan reviewed and signed off — in writing, linked in the Jira task. Verbal quota agreements create problems at the end of the quarter.
- First prospect meeting attended (shadow) — Week 2 at the latest. The fastest way to learn what customers actually say.
HR / People Ops additions (6 tasks)
- HRIS system access provisioned — if you use BambooHR, Personio, or another HRIS alongside Jira, provision access on Day 1 with the specific modules they need (not admin access on Day 1).
- Payroll system access and first payroll run verified — confirm the new hire appears correctly in payroll before their first payday. A task with due date 3 days before payroll close.
- Benefits administration access — if HR manages benefit enrollments, they need carrier portal access. Create the task with a specific carrier login URL.
- Employee handbook and policy library reviewed — link the Confluence space. Add a task for the hiring manager to confirm the new HR team member has reviewed it, not just a self-reported checkbox.
- Confluence HR space edit access — HR team members need contributor access, not just view access. Distinct from read access to the general team wiki.
- Onboarding process ownership introduced — the new HR person will run future onboardings. Walk them through this checklist explicitly so they can maintain and improve it.
What the checklist misses without Jira-specific knowledge
Several onboarding steps look simple but create real problems if you handle them wrong in Jira specifically.
Jira notifications are overwhelming by default
A new hire added to a Jira project with default notification settings gets emailed on every issue creation, status transition, comment, and assignment in that project. A busy engineering project generates 40–80 emails per day. New hires typically turn off all Jira email notifications within their first week, which means they stop getting assignment notifications entirely. Walk new hires through Project Settings → Notifications and set up a custom notification scheme that emails on "Assigned to Me" and "Mentioned" only.
The 36-status trap
Teams that try to track onboarding in their engineering workflow end up adding statuses for each step: "Laptop Ordered," "Laptop Shipped," "Laptop Received," "Laptop Configured." This creates a workflow with 20+ statuses that Jira's board view renders as a horizontal scroll of tiny columns. Once a Jira workflow has more than about 12 statuses, the board view becomes impractical. The fix is to keep the onboarding workflow to 3 statuses (To Do, In Progress, Done) and use task names and due dates to express the detail, not status transitions.
Sub-tasks are not visible on sprint boards
If you create onboarding tasks as sub-tasks of a parent Epic in an engineering project, those sub-tasks do not appear on sprint boards unless you add them to a sprint explicitly. IT admins who use the sprint board as their todo list will not see them. Either use a separate project (recommended) or add onboarding sub-tasks to the IT sprint explicitly each time a new hire starts.
Frequently asked questions about Jira onboarding checklists
What should be on a Jira onboarding checklist?
A complete Jira onboarding checklist covers four phases: Day 1 (IT setup, account provisioning, badge access), Week 1 (dev environment, security training, first sprint tasks), Month 1 (30-day review, full project access, goals documented), and the 90-day mark (access audit, onboarding Epic closed). Most teams need 20–30 tasks minimum, grouped by department: IT, HR, Manager, and the new hire's own team.
How do I create an onboarding checklist in Jira?
Create a parent Epic named "Onboarding – [New Hire Name]" with a start date of their first day and a due date at the 90-day mark. Add Components for each department (IT, HR, Manager, Security) and create sub-tasks under each. Use a dedicated Onboarding project with a 3-status workflow (To Do, In Progress, Done) rather than your main development workflow — onboarding tasks do not map to engineering statuses, and mixing them creates noise on sprint boards.
How many tasks should a Jira onboarding checklist have?
Most engineering onboarding checklists need 20–30 tasks for a full 90-day period: 8–12 for Day 1 (hardware, accounts, access), 5–8 for Week 1 (training, first assignments), 5–8 for Month 1 (review, access promotion), and 3–5 for the 90-day mark. Role-specific checklists for Engineering, Sales, and HR typically run 20–25 tasks each once you add department-specific items.
What is the difference between onboarding tasks in Jira and a Jira onboarding workflow?
Onboarding tasks are individual checklist items (provision a laptop, schedule a welcome meeting). An onboarding workflow is a Jira status sequence (To Do → In Progress → Done). The mismatch is that HR onboarding is a parallel checklist across multiple departments, but a Jira workflow is a linear status chain for a single issue. The most effective approach is a minimal 3-status workflow on the parent onboarding Epic, with each department's tasks as separate sub-tasks or Components assigned to the right owner.
If manually creating 30 tasks per hire is the bottleneck: TeamOps (by PPLX Software) is a Forge-native Jira app that creates this full task structure automatically when you start an onboarding — role-based templates, phase organization, department assignment. Most HR apps bolt onto Jira from outside; TeamOps runs natively on Atlassian and ships a Rovo agent so your team can manage onboarding and leave in the tools they already use (Rovo requires Jira Premium or Enterprise plan). Free for teams up to 10 users.
How to keep the checklist current
Onboarding checklists decay. Tools change, policies update, roles evolve. Three practices that keep the list usable:
- After every onboarding, add a task: "Review onboarding checklist for gaps." The 30-day check-in is when new hires are most likely to remember what was missing from their first week. Capture it while it's fresh.
- Version the template: If your Jira Automation rule or Confluence template generates the task list, keep a version history. When you change the template for a new role, make sure existing onboardings don't get duplicate or conflicting tasks.
- Audit access as part of offboarding: The access granted during onboarding is the same access that needs to be revoked at offboarding. If your onboarding list is accurate, your offboarding checklist is half-written already.
If manually creating 30 tasks per hire is eating your time, TeamOps automates it inside Jira. Install free for up to 10 users