Absence management for Jira and Jira Service Management
Team members request time off from their personal settings, the approvers you configure decide, and while someone is away their open issues go to a substitute, in the projects you choose. When they are back, the app hands the work back.
Free trial through the Atlassian Marketplace. Billed through your Atlassian account.
What it does
Team members request time off from their personal settings. The approvers you configure decide, with a note if needed. Nobody approves their own absence.
While an approved absence is active, open issues in the projects you choose go to the substitute. Once it has ended, the app hands them back.
A hint on the issue says who covers and until when. A team calendar shows who is out on which day — also as a dashboard gadget, or exported to your own calendar. If someone assigns work to an absent colleague, a warning comment follows.
How it works
An absence moves through a small set of clear states: pending, approved, active, completed. Each step does one thing, and the requester can cancel along the way.
A team member picks an absence type, the dates, a substitute and, if they like, a private reason. The request appears in their own list immediately.
It goes to their team’s approvers or to the sitewide approver pool. An approver or a Jira administrator approves or declines it, optionally with a note. With approvals switched off, it is approved automatically.
Within the hour after midnight on the start date, in the reference timezone you set, the absence becomes active and the person’s open issues in the covered projects are reassigned to the substitute.
Once the last day has passed, the issues the substitute still holds go back to the person and the absence is completed.
The issue is unassigned. You are about to assign it to Lena Fischer.
Features
Each function states beside its name whether it can change a Jira issue. Most of the app only stores absences in its own storage; only coverage and the warning comment touch issues.
Every Jira user requests time off from their own personal settings, and keeps track of it in one place.
The app’s global page: an approval queue for the people who decide, and a calendar of who is away.
While an approved absence is active, open work goes to the substitute, in the projects an administrator chose, and comes back afterwards.
Where most people notice an absence: on an issue assigned to someone who is out.
One settings page under Jira settings → Apps, for Jira administrators only, with safe defaults so nothing blocks Jira before it is configured.
Keep personal data to what the work needs, and delete it when it is due. Everything stays in Forge storage for your site.
For service desks and larger teams
Jira has no manager field, and a service desk queue does not wait for anyone’s holiday. The app makes absences an explicit, accountable process instead of a chat message.
A sitewide approver pool, optional teams with their own approvers, individual users or Jira groups. A team’s members can come from an Atlassian Team. Group membership is checked live at the moment of the decision.
Nobody can decide their own request, checked on the server against the stored record. Every settings change is logged with who made it and when.
If the substitute cannot be assigned an issue, for example because they are not a member of that project, the issue is skipped and counted on the requester’s page rather than lost.
An hourly job finds the absences that are due and queues them; a background worker pages through the issues. The work is idempotent, so a second run never assigns or reverts twice.
Security & privacy
The app runs entirely on Atlassian Forge. There is no vendor infrastructure in the path, and we as the vendor never receive your data.
| Question | Answer |
|---|---|
| Where does the app run? | Entirely on Atlassian Forge, inside your Atlassian tenant. |
| Does any data leave Atlassian? | No. The app declares no external endpoints and makes no external calls. The only APIs it calls are Atlassian’s own. |
| Are there sub-processors? | None. No data is sent anywhere. |
| Who sees an absence reason? | By default the requester and an authorised approver. Never on an issue, never in a log. |
| What is stored? | Absence records, the configuration, a configuration change history and, for at most 15 minutes, the members of linked Atlassian Teams, in Forge storage inside your tenant. |
| Can personal data be deleted? | Yes. An administrator can delete all data of a person in one step, an optional retention period deletes finished absences, and data of accounts Atlassian reports as closed is deleted every week. |
| What happens on uninstall? | Atlassian deletes the app’s storage: it is kept for 28 days, then permanently deleted. Warning comments and a small marker without personal data stay on the issues, as part of their history. |
Use cases
Each guide walks through one situation with the parts of the app that handle it, and names what to watch out for.
Keep a service desk moving while an agent is on holiday.
Read moreRoute time-off requests to the right approvers, and see who is away.
Read moreHand open issues to a substitute while away, and get them back afterwards.
Read moreRecord sick leave without telling the whole company someone is ill.
Read moreGetting started, every setting explained, how coverage works, FAQ and troubleshooting.
Read morePricing
Small instances
Free
On Jira sites with up to 10 users, with every feature.
From 11 users
Per user
Priced on your Jira user tier: all Jira users, not only service desk agents. The Marketplace shows the price for your tier.
Without an active subscription
Paused
New requests, decisions, settings changes and the on-demand coverage run show a clear “subscription required” message instead of an error.
FAQ
Set up absence types, approvers and one covered project in about 10 to 15 minutes. Jira keeps working while you do.
Out of Office & Absence Planner