Jira Onboarding Template: Epic, Sub-tasks, and Automation

A Jira onboarding template is the Automation rule configuration that turns one trigger — an Epic created with the label "new-hire" — into a fully-formed onboarding structure: per-hire Epic, 20 sub-tasks, department Component assignment, and due dates keyed to the hire start date. PPLX Software (maker of TeamOps, our Atlassian app) built and iterated on this setup across hundreds of hires; the field values and wiring steps below replicate it without any additional tooling.

Two decisions determine whether the template holds up at scale. First, every sub-task's due date must be expressed relative to the hire date, not a fixed calendar date — otherwise a single reschedule requires manually editing 20 tasks. Second, use Jira Components (not labels) for department ownership, because Components support default assignees, which routes each task to the right person automatically.

The template: 20 sub-task actions

Each row is one "Create issue" branch action in the Automation rule. Set Issue type to Sub-task and Parent to {{issue.key}} (auto-links to the triggering Epic) on every action. The Due date column shows the Smart Value expression to paste into the Due date field.

Wiring the Automation trigger

Open Jira → Project Settings → Automation → Create rule. Use these exact settings:

1. Trigger: Issue created. Scope it to the HR Operations project (not global), unless you need tasks created in multiple projects — in which case a global rule and Premium tier are required.
2. Condition: Issue type = Epic AND Label = new-hire. Without the label condition, the rule fires for every Epic created in the project, including non-onboarding Epics. Add the label manually when creating each new hire's Epic, or create a second rule that adds the "new-hire" label automatically when the Epic summary starts with "Onboarding –".
3. Action: Branch rule / related issues → Create issue. Add one branch action per sub-task in the 20-action template. Set Issue type to Sub-task on each. The Parent field is pre-filled to the triggering Epic; leave it as is.
4. Component field: Add the Component field to each "Create issue" action and set it to the value in the Component column above (IT, HR, Manager, Security, or Engineering). Components must already exist in the project before the rule fires — create them under Project Settings → Components before deploying the automation rule.

Component vs label for department ownership

Labels route tasks visually but do not support default assignees. A sub-task labeled "IT" lands unassigned unless someone manually sets the assignee. Components support default assignees at the project level, which means IT tasks route to the IT admin automatically when the rule fires.

The practical consequence: with labels, every IT sub-task needs its Assignee field filled in manually during task creation — either in the automation rule (where you must hard-code a specific user, breaking when that person changes) or after the fact (where it frequently gets skipped). Components eliminate that choice. Set the default assignee once per Component, and the routing holds for every future hire without touching the automation rule.

Use labels as secondary classification if you need them (for example, "engineering-onboarding" as a label on role-specific tasks), but make Components the department ownership mechanism.

Role-specific field changes

The 20 tasks above apply to every hire. Role-specific tasks extend the base template without duplicating it.

Engineering additions (6 tasks)

Add these after task 14, with due dates as shown:

• Repository access granted — specify which repos; "GitHub access" without a list grants read-only on everything and write on nothing — due: {{issue.startDate}}
• CI/CD pipeline walkthrough — branch → PR → review → merge → automated deploy, done once as a live session, not as documentation to read — due: {{issue.startDate.plusDays(5)}}
• Code review process documented and reviewed — link the team's PR guide in Confluence; new engineers need response time expectations and merge authority, not just "we do code review" — due: {{issue.startDate.plusDays(5)}}
• First bug fixed and merged — a shippable task with a ticket number and merge commit; a cleanup task does not count — due: {{issue.startDate.plusDays(14)}}
• Architecture overview session completed — 60 minutes with a senior engineer; not optional for the template to produce independent contributors — due: {{issue.startDate.plusDays(14)}}
• On-call rotation added — not Month 1; due at day 60 gives time to get fully settled before carrying a pager — due: {{issue.startDate.plusDays(60)}}

Sales additions (5 tasks)

• CRM access provisioned and sandbox configured — name the specific CRM objects (Accounts, Contacts, Opportunities); "CRM access" without specifics means login but no usable permissions — due: {{issue.startDate}}
• ICP documentation reviewed — link the Confluence page; if it does not exist, create it before the hire's first day — due: {{issue.startDate.plusDays(3)}}
• Product demo certification — full demo delivered to the hiring manager before Week 3; set the due date on Day 1 so the deadline exists before the week fills up — due: {{issue.startDate.plusDays(14)}}
• Quota and comp plan signed off — in writing, linked in the task; verbal quota agreements break at quarter end — due: {{issue.startDate.plusDays(5)}}
• First prospect meeting attended (shadow) — Week 2 at the latest; listening to real customer calls teaches faster than reading call transcripts — due: {{issue.startDate.plusDays(10)}}

HR / People Ops additions (4 tasks)

• HRIS access provisioned with role-appropriate modules — specify which modules (Employees, Benefits, Payroll), not admin access on Day 1 — due: {{issue.startDate}}
• Payroll system access verified before first pay run — due 3 days before payroll close; missing this delays the first paycheck — due: {{issue.startDate.plusDays(11)}}
• Confluence HR space contributor access — edit access, not view-only; the HR team member needs to update the very pages they were just walked through — due: {{issue.startDate}}
• Onboarding process ownership introduced — the new HR person will run future onboardings; walk through the Automation rule and Component setup so they can maintain and update it — due: {{issue.startDate.plusDays(7)}}

Two field configurations that break silently

The Assignee field versus Component default. If you set a specific Assignee in the "Create issue" action, you are hard-coding a person into the Automation rule JSON. When that person leaves or changes roles, every future hire gets their tasks routed to the wrong place, with no error message. Leave the Assignee blank in the action and rely on the Component default assignee. Update the Component default when someone changes roles; the Automation rule needs no edit.

The Due date field must be a Smart Value, not a static date. Jira's "Create issue" action in Automation accepts both static dates and Smart Value expressions in the Due date field. Static dates work for the first hire. By the third reschedule, you have 20 sub-tasks with due dates that no longer match the hire date and need a bulk edit. Smart Value expressions like those in the 20-action template resolve correctly whenever the rule fires, regardless of when that is.

At teams hiring three or more people per month, maintaining the Automation rule JSON as the onboarding task list evolves becomes its own overhead — new tasks, changed owners, updated due date windows. TeamOps ships the per-hire Epic, the Component-based ownership split, and these 20 sub-tasks as an editable role template inside Jira itself: you update the task list in the TeamOps admin screen rather than in Automation rule JSON, and the changes propagate to the next hire automatically. Free for teams up to 10 users.

Frequently asked questions

Do I need Jira Automation Premium to use this template?

Not if the onboarding project is self-contained. Jira Automation's multi-action rules run on the Free and Standard plans for team-managed projects. Premium is only required for global rules that create tasks across multiple projects simultaneously. If you want IT tasks in a separate IT project and HR tasks in an HR project, that cross-project action requires Premium. The straightforward alternative: keep all 20 sub-tasks inside one dedicated HR Operations project with Components for department filtering — single-project rules work on Free.

What happens if a hire date changes after the Automation rule has created the sub-tasks?

Smart Value expressions resolve at the moment the "Create issue" action fires. After that, each sub-task's due date is a fixed calendar date. Changing the parent Epic's start date does not cascade. Fix it with a bulk edit: from the Epic's sub-task list, select all, choose Bulk Change → Edit Fields → Due Date and set the corrected phase date per group. For teams that reschedule frequently, a second Automation rule triggered by "Epic start date changed" can bulk-update linked sub-tasks automatically.

Onboarding access granted is offboarding access revoked — the offboarding checklist maps directly onto the Components and task structure set up here.