Atlassian PTO: Setting Up Leave Requests in Jira

Atlassian's Jira handles PTO tracking the same way it handles everything else: through issues, workflows, and automation rules. That's both its strength and its friction. There's no dedicated leave calendar in base Jira, no approval inbox, and no out-of-the-box way to show who's out next week. What Jira does have is enough flexibility to build all of that yourself — if you set it up correctly from the start.

This is the configuration that works past the first 20 employees without requiring a Confluence spreadsheet alongside it.

Project and issue type setup

PTO requests should live in a project separate from engineering or product work. Mixing them creates two problems: leave requests surface in sprint planning views, and the statuses engineers use (In Sprint, Code Review, Blocked) have no meaning for an HR approval flow.

Create a new Scrum-style project named HR Operations with the key HROPS. Then go to Project Settings → Issue Types and add a new type called Time-Off-Request. Use the built-in "Support Request" icon (green). This is not a Task, not a Story — it's a purpose-specific issue type that won't contaminate velocity charts or backlog reports.

Under Project Settings → Fields, add these custom fields to the Time-Off-Request screen only:

Don't add a "Return Date" field — it's always End Date + 1 business day, and a separate field creates a data consistency problem when someone changes their end date after submitting.

The approval workflow

Go to Project Settings → Workflows → Create new workflow named Leave Approval. Four statuses cover the full lifecycle without adding noise:

• Submitted (initial status) — the requester created the issue and it's pending routing
• Manager Review — routed to the manager, awaiting decision
• Approved (terminal) — leave confirmed
• Rejected (terminal) — leave denied, requester notified

Set up four transitions:

1. Submitted → Manager Review (any user, triggered by automation)
2. Manager Review → Approved (restricted to Jira group hr-managers)
3. Manager Review → Rejected (restricted to hr-managers)
4. Rejected → Submitted (any user, allows resubmission with corrections)

Assign the Leave Approval workflow to the Time-Off-Request issue type only. Your engineering tasks and other issue types keep their existing workflows unaffected.

Automation rule: route to manager on submission

The most useful automation rule for PTO in Jira runs on every new Time-Off-Request submission. Go to Project Settings → Automation → Create rule.

Trigger: Issue created (or status changed to Submitted if you allow draft saving)

Conditions: Issue type = Time-Off-Request

Actions (in order):

1. Edit issue → set Manager field to {{issue.reporter.manager}} — this requires manager relationships configured in your Atlassian organization directory under admin.atlassian.com → Directory → Managed accounts. If that's not set up, use a lookup table automation instead (see note below).
2. Edit issue → set Assignee to {{issue.Manager}}
3. Transition issue to Manager Review
4. Send email to {{issue.assignee}} with subject "PTO request from {{issue.reporter.displayName}} — please review"

If your Atlassian directory doesn't have manager relationships populated, the {{issue.reporter.manager}} smart value returns empty, and the assignee write silently fails. The workaround is a lookup automation that reads a custom "Manager Mapping" issue in HROPS — a single issue with a table in its description matching each employee to their manager user ID. Updating that issue when org chart changes happen is manual, but it's the only option in base Jira without a user management plugin.

Confirmation email to the requester

Add a second rule triggered by status transition to Approved or Rejected. Action: send email to {{issue.reporter}} with leave details from the Start Date, End Date, and Leave Type fields. Include the decision in the subject line. Requesters who only get a Jira notification miss it if they've muted Jira emails; a separate email from Automation arrives as a distinct sender and has a higher open rate.

Making approved PTO visible to the team

Base Jira has no leave calendar. The workaround is a saved Issue Navigator filter shared with the whole team.

Create a filter with this JQL:

project = HROPS AND issuetype = "Time-Off-Request" AND status = Approved AND "Start Date" >= startOfMonth() ORDER BY "Start Date" ASC

Save it as "Team PTO — current month" and share it with the jira-users group. Everyone with Jira access can open Issue Navigator, load the saved filter, and see who's approved to be out. Switch startOfMonth() to startOfWeek() for a week-ahead view.

For a visual calendar view, open the HROPS board and select Calendar from the board view toggle (available in Jira Cloud's board view for both team-managed and company-managed projects). The Calendar view shows issues on a date field you pick in the board's Calendar settings — set it to your Start Date custom field so each approved request appears on the day the absence begins rather than the day it ends. Filter the calendar to "Status = Approved" to hide pending requests. Weekly view shows day-by-day coverage gaps, which is faster to read than the Issue Navigator list when you're checking sprint capacity.

Where the Jira Automation approach reaches its limit

The setup above works well for orgs with stable manager relationships and under about 50 employees. Two things break it in practice:

Org chart changes. When someone's manager changes, the automation still routes new requests to the old manager until you update the Atlassian directory or the lookup mapping table. There's no webhook in Jira that fires on user attribute changes — you have to catch the manager change separately and update the routing. Teams that go through a reorg typically discover this two weeks later when requests pile up unreviewed in a departed manager's queue.

Multi-level approval. If HR needs to confirm after the manager approves, you need a fifth status (HR Review), a third approval transition, a second automation rule, and a separate hr-staff permission group. Each layer doubles the maintenance surface. By the time you add a second approver, the automation rule set has drifted from whatever someone documented in Confluence six months ago.

The HR-OPS project, the Time-Off-Request issue type, the Manager field, and the Submitted → Approved workflow you just built are exactly the structure TeamOps creates automatically on install — with the manager mapping stored in the app rather than in the Atlassian directory, so an org-chart change updates the routing without touching a single automation rule. For teams that hit the org-change problem before they have bandwidth to debug automation, that's the specific thing it removes.