Blog ·
Jira for HR: onboarding, requests, and the people calendar
Jira for HR works best as three pieces in one project: an onboarding workflow that follows a new hire from offer to first day, a queue for requests from employees and managers, and a people calendar of recurring tasks that never depends on somebody remembering. The first two are what most guides cover. The third is where HR teams lose the most time, because probation checks, review cycles and compliance renewals arrive on a date and nobody files a request for them. This guide sets up the first two quickly, then spends most of its length on the third.
Statements about Jira's built-in features are as of October 2026, from Atlassian's own pages.
Why HR teams end up in Jira #
Usually because the rest of the company is already there. IT needs to provision a laptop for each new hire, facilities needs a desk, and a manager needs an account set up. Those teams already work from Jira queues, so HR tickets reach them with no hand-off. A single tool also gives HR a record of who asked for what and a way to show workload.
Jira suits HR work that is:
- made of steps with different owners, such as offer accepted, equipment ordered, accounts created, first day;
- request driven, such as a manager asking for a role change or an employee asking for a letter;
- tied to dates, such as probation end dates, annual reviews and training renewals;
- visible at the level of status to people outside HR, while the records themselves stay in your HR system.
It is a weaker fit for storing personnel records, payroll data or anything confidential about an individual. Keep those in the system built for them and link out from the ticket.
Start from Atlassian's HR template #
Atlassian publishes a category of HR templates for Jira. As of October 2026 its templates page lists one in the category:
| Template | What Atlassian says it is for |
|---|---|
| Employee onboarding | "Manage the onboarding process from offer acceptance to day one on the job." |
That is a sound starting point for an onboarding project. Treat it as a draft. Rename the statuses to the words your team already uses, remove the fields nobody fills in, and add the one or two that matter to you, such as the start date and the hiring manager.
Set up the onboarding workflow #
Onboarding is the same sequence for every hire, which makes it a good fit for a Jira workflow. A typical one:
| Status | Who acts | Leaves the status when |
|---|---|---|
| Offer accepted | HR | Start date and role are confirmed |
| Preparing | HR, IT, facilities | Equipment, accounts and desk are ready |
| Week one | Manager | The first-week plan is done |
| Check-in | HR and manager | The 30 day conversation has happened |
| Done | Nobody | Probation dates are recorded |
Two choices make it work. Give each hire one parent ticket with subtasks per owner, so IT sees only its own steps and HR sees the whole picture. And put the start date in a field, so a filter can show every hire starting this month. Our Jira subtask template guide covers four ways to get the same subtasks every time, and where checklist steps should live covers when a checklist beats a subtask.
The last row matters more than it looks. When onboarding closes, the probation end date and the first review date are known. Those dates are the start of the next piece of work, and they are the pieces most teams lose.
Set up the request queue #
A request queue is how employees and managers reach HR. A few choices help:
- Give each request its own work type or label: employment letter, role change, leave question, equipment. Reporting by type is how you show where the time goes.
- Ask for the essentials up front: who it is about, the date it is needed by, and the manager's approval where one applies.
- Assign on intake, even if only to a triage owner. An unassigned request is one everybody assumes somebody else has.
- Keep sensitive matters out of the shared queue. Grievances, investigations and anything about one person's health or pay belong in a separate project with tighter permissions.
The fourth point depends on your plan. Atlassian's page on the Free plan says permissions, roles and work-level security are not customisable there, so an HR team that needs restricted projects should plan on a paid plan.
The people calendar nobody files a request for #
Requests come from people. The recurring tasks come from the calendar. Here is a typical HR routine:
| Task | Cadence | What goes wrong without a ticket |
|---|---|---|
| Probation review prompt to managers | Weekly check for upcoming end dates | A probation period ends with no decision |
| Performance review cycle kickoff | Twice a year | Reviews start late and bunch up |
| Compliance and safety training renewal | Yearly | Certificates lapse unnoticed |
| Right-to-work or contract expiry check | Monthly | A contract runs out with no renewal |
| Payroll cutoff reminder | Monthly | Changes arrive after the cutoff |
| Engagement survey run | Quarterly | The survey slips a quarter |
| Leave balance and year-end carry-over review | Yearly | Balances are corrected in a hurry |
Each is easy to do and easy to forget. They live in a spreadsheet or one person's calendar, and when that person is away the date passes. A recurring task should create its own ticket, assigned and dated, ahead of the deadline rather than on it.
Three ways to make the calendar create tickets #
| Create by hand | Jira Automation scheduled rule | Recurring Work Items for Jira | |
|---|---|---|---|
| Effort | Every ticket, every cycle | One rule per task, written once | One rule per task, chosen from a form |
| Schedule | Whoever remembers | Fixed rate or cron expression | Daily, weekly, or monthly on a day or a weekday, every N months |
| Lives in | Somebody's calendar | The automation rules list | The HR project itself |
| When it misses | Nobody knows | Check the rule's audit log | Run history with the reason |
By hand #
Fine for a handful of tasks. One person owns the people calendar and creates the tickets at the start of each month, ideally by cloning last cycle's. Our Jira task template guide makes those clones quick. The risk is the one above: the calendar has a single owner.
Jira Automation #
Jira's own automation can create a work item on a schedule. Atlassian's trigger reference says you can run the flow "at a fixed rate (for example, every 7 days), or use a Cron expression for more complex schedules." That covers most HR routines. Two things to plan for. A date like "the last working day of the month" is awkward to say in cron, and our Jira cron expression guide covers the gaps. And every run counts toward your plan's monthly automation usage, which Jira Automation pricing explains.
A scheduling app #
Recurring Work Items for Jira is built for this job. Its rules are scoped to one project, so the HR team's calendar lives inside the HR project rather than in a site-wide rules list that other admins edit. A project administrator turns it on for the project, and a rule made there creates work only there.
Set up the people calendar with Recurring Work Items #
- Open the HR project and turn the app on for it.
- Create one rule per task. A twice-yearly review kickoff is a monthly rule repeating every 6 months; a quarterly survey repeats every 3 months.
- Pick the day. "The 1st" or "the last Friday of the month" are both choices in the form.
- Set your working days and holidays, so a rule that would land on a weekend or a public holiday moves to a working day. Our Jira holidays guide covers what each holiday setting changes.
- Write the title with tokens so each cycle's ticket is distinct, for example
Mid-year review kickoff {{now.year}}. - Fill in the template: the owner, a due date a set number of days after the run, labels, and a description that says where the policy or checklist lives.
- Add subtasks where the task has steps, such as pull the list, notify managers, collect forms, close the cycle.
Create the ticket early. For a review cycle that managers must finish by the end of the quarter, schedule the kickoff weeks ahead and put the real deadline in the due date. The ticket's job is to start the work, not to mark the last possible day.
A rule can be given an end, either a date or a number of runs. That suits tasks that stop, such as a quarterly check during a restructure.
Every run is recorded in the rule's history as created, skipped or failed, with the reason. When an auditor asks whether last year's training renewal was raised, the history and the ticket together answer it.
Report on HR work #
A few saved filters do most of the reporting:
- open requests by type, to show where the time goes;
- requests older than your target, to spot what is stuck;
- hires starting this month and the status of their onboarding;
- this quarter's recurring tasks and their status, for the leadership update.
Our Jira weekly report guide shows how to turn a filter into an emailed summary, which is often all the business needs from HR each week.
When the manual way is enough #
A recurring schedule earns its keep once the calendar is bigger than one person's memory. You probably do not need one if:
- you are a team of one or two with a short list of dates you already track reliably;
- your HR system already reminds the right people, with probation and review prompts built in;
- almost all your work is reactive, so the request queue is the whole job.
Once the routine runs into dozens of tasks, or the person who holds the calendar is away for a month, a missed date costs more than the setup.
FAQ #
Is there a Jira template for HR? Yes. As of October 2026 Atlassian lists an employee onboarding template in its HR category.
Should HR use Jira or Jira Service Management? Jira works for an internal team that takes requests from colleagues. A team that wants a request portal for the whole company, with forms and queues, may prefer Jira Service Management.
Can Jira remind us when a probation period ends? Not on its own from a date field. You need a scheduled rule, either in Jira Automation or in an app such as Recurring Work Items for Jira, that creates the review ticket ahead of the end date.
Can sensitive matters stay private? On a paid plan, yes, with a separate project and its own permissions. On the Free plan Atlassian says permissions are not customisable.