Out of Office & Absence Planner
Deutsch Get the app

Every function, and whether it touches your issues

Eighteen functions in six areas. Each states beside its name whether it can change a Jira issue. Most only store absences in the app’s own storage.

2 · functions

Absence requests

Every Jira user requests time off from their own personal settings, and keeps track of it in one place.

Request an absence

No issue changes

A short form on the personal settings page: absence type, start and end date, an optional substitute and an optional reason.

What you get

  • Absence types defined by your administrator, such as vacation, sick leave or training.
  • A substitute chosen from your site’s users, who takes over open work while you are away.
  • A free-text reason that is optional and treated as private.

Safeguards

  • A request is always recorded for the signed-in user. Nobody can file one on someone else’s behalf.
  • Every field is validated on the server: dates, type, lengths. The reason is limited to 1,000 characters.
  • When coverage is set up, the substitute must be assignable in a covered project where you may assign issues yourself.

My absences

No issue changes

Your own requests with their status: pending, approved, starting, active, declined, cancelled or completed.

What you get

  • The approver’s note on a decided request.
  • Cancelling your own request. Cancelling a running absence hands your issues back straight away.
  • A clear notice with the number of affected issues when some of your open issues could not be handed to your substitute, or back to you.

Safeguards

  • Only the owner of a request can cancel it. “Not found” and “not yours” look the same, so nobody can probe for other people’s records.

4 · functions

Approvals & team view

The app’s global page: an approval queue for the people who decide, and a calendar of who is away.

Approval queue

No issue changes

Pending requests for the approver to approve or decline, with an optional note for the requester.

What you get

  • Requests routed to the right people: a team’s own approvers, or the sitewide approver pool.
  • Approvers named individually or as Jira groups, where anyone currently in the group may decide.
  • Approvals that can be switched off entirely, so requests are approved automatically.

Safeguards

  • Nobody can decide their own request, re-checked on the server against the stored record.
  • A team approver decides only requests from their own team. Group membership is checked live at the moment of the decision.
  • Only a pending request can be decided. If two approvers click at once, the first decision stands.

Team calendar

No issue changes

A month calendar of who is away on which day, beside a detailed list of upcoming and ongoing absences.

What you get

  • Type, dates, status and substitute for each absence, in Jira Software and Jira Service Management alike.
  • Who sees whose absences is an administrator’s choice: all Jira users, members of the same team, or approvers and admins only.

Safeguards

  • For a type marked sensitive, such as sick leave, others see only “Absent”. This is enforced on the server.
  • Reasons stay hidden unless an administrator opts in, and the reason of a sensitive type stays hidden even then.
  • A browser never receives an absence, type or reason the viewer is not entitled to see.

Export and dashboard gadget

No issue changes

Take the overview with you: download it as a calendar or spreadsheet file, or put it on a Jira dashboard.

What you get

  • A calendar file (.ics) to import into Outlook, Google Calendar or Apple Calendar, and a spreadsheet file (.csv) for Excel or Google Sheets.
  • The gadget “Out of Office — Who is away” on any Jira dashboard: who is out now, and who goes away in the next two weeks.

Safeguards

  • Export files are built in your own browser. Nothing is sent anywhere, and the app still makes no external call.
  • An export contains only the absences you were already allowed to see, and never the private reason — a downloaded file leaves the app’s protections behind.
  • The gadget reads the same data as the calendar, so adding it to a dashboard grants nobody any extra sight.

Search for absent people

No issue changes

An optional JQL function that finds work sitting with someone who is away: assignee in oooAbsentUsers().

What you get

  • Works with assignee, reporter and creator, and with the operators “in” and “not in”, anywhere Jira accepts JQL.
  • Combine it like any other query, for example with statusCategory != Done to find work nobody is picking up.

Safeguards

  • Switched off until an administrator opts in, and only available where absences are visible to all users: Jira works the answer out once for the whole site and does not tell the app who is searching.
  • It discloses only that a person is away — never the absence type, never the reason. It deliberately takes no arguments, so it cannot be asked who is on sick leave.
  • Jira caches the answer for the whole site, so the app refreshes it every hour; a search is at most an hour behind.

2 · functions

Substitute coverage

While an approved absence is active, open work goes to the substitute, in the projects an administrator chose, and comes back afterwards.

Automatic reassignment

Changes issues

When an approved absence starts, the person’s open issues in the covered projects are reassigned to their substitute.

What you get

  • Open means not in a Done status category, so finished work is left alone.
  • The app records which issues it moved, so it can hand back exactly those.
  • An hourly job starts absences within the hour after midnight on their start date, in the reference timezone your administrator sets.

Safeguards

  • Coverage never runs instance-wide: only in the projects an administrator selected, and only where the absent person may assign issues themselves.
  • Issues the substitute cannot be assigned to are skipped and counted on the requester’s page, never silently dropped.
  • The work is idempotent: running it again never assigns anything twice.

Hand back on return

Changes issues

Once the last day of the absence has passed, the issues the substitute still holds go back to the person who was away.

What you get

  • Every issue the app moved and the substitute still holds, including ones resolved in the meantime.
  • The list of moved issues is deleted once coverage has ended.

Safeguards

  • Issues the substitute passed on to someone else stay where they are.
  • Handing back never needs an active subscription, so issues are never stranded with a substitute.
  • An absence that was approved but never became active is simply closed.

2 · functions

On the issue

Where most people notice an absence: on an issue assigned to someone who is out.

Out-of-office hint

No issue changes

On an issue whose assignee is currently away, a small panel shows “out of office until” the return date and who is covering.

What you get

  • The return date and the substitute, at a glance in the issue view.
  • Nothing at all when the assignee is present, so it never adds noise.

Safeguards

  • Never shows a reason or the absence type.
  • Only for signed-in users; the issue is read with the viewer’s own permissions.

Assign-to-absent warning

Changes issues

When an issue is assigned to someone who is out of office, the app posts a comment naming the absence’s end date and the substitute.

What you get

  • The person who assigned the issue notices the absence straight away.
  • A setting to switch the warning off, and one site-wide comment language: English or German.

Safeguards

  • Internal on Jira Service Management requests: the customer never sees it in the portal. On Jira Software issues it is a normal comment.
  • Posted at most once per issue and absence, and only in the projects the app works in.
  • Reactive by design: Forge cannot block an assignment as it happens, so the comment follows just after it.

5 · functions

Administration

One settings page under Jira settings → Apps, for Jira administrators only, with safe defaults so nothing blocks Jira before it is configured.

Settings

No issue changes

Absence types, approvers and teams, the projects the app works in, reassignment policy, reference timezone, visibility and the warning comment.

What you get

  • Absence types with your own labels, each with a “sensitive” flag. Vacation, sick leave (sensitive), training and other ship as a starting set.
  • A sitewide approver pool and optional teams, each with members and their own approvers, as users and Jira groups.
  • A reassignment policy: reassign all open issues to the substitute, or none.

Safeguards

  • Every read and save re-verifies Jira administrator permission on the server; the page’s location is not treated as access control.
  • Every value is validated on save, with an actionable message.

Teams from Atlassian

No issue changes

Link one of the app’s teams to an existing Atlassian Team, so its members come from Atlassian and stay up to date.

What you get

  • A search for Atlassian Teams, showing each team’s name and member count.
  • Members read from Atlassian when needed and kept for at most 15 minutes. Approvers are still chosen in the app.

Safeguards

  • Searching teams is for Jira administrators only and returns names and member counts, never member lists.
  • Fail-closed: a team that cannot be read counts as having no members, so requests go to the approver pool and visibility shows less, never more.
  • Read-only: the app never changes an Atlassian Team. Teams anyone can join are ignored for same-team visibility.

Change history

No issue changes

A running log of configuration changes: who changed the settings, when, and which settings changed.

What you get

  • The 100 most recent changes on the settings page.
  • An entry when a person’s data was deleted, with counts, never whose data it was.

Safeguards

  • Records which settings changed, never their values, so the log itself cannot leak configuration such as who is in a pool.

Built-in help

No issue changes

A Help tab that answers what the app can do, what the rules are, and why something is not available on this site.

What you get

  • A searchable index of the full manual, linking straight into it — readable without an Atlassian account.
  • A table of what this site has switched on: approvals, coverage, visibility, the absence search, holidays and retention.
  • The statuses explained, the rules a request must meet, and what the app never does.

Safeguards

  • The index is generated from the same documentation that is published, so the app cannot advertise a chapter the manual no longer has.
  • The limits are reported by the running app, not written down twice, so a number someone plans around is the one actually enforced.
  • It shows counts and switches only — never project names, team names, holiday dates or people — so it cannot be used to read the configuration.

Run activation now

Changes issues

Runs the hourly coverage job immediately: absences due today are activated, ended ones handed back.

What you get

  • Coverage applied right after a settings change or while testing, without waiting for the next hourly run.
  • Counts of the activations and expiries queued, and of any that failed to queue.

Safeguards

  • Administrators only, re-checked on the server.
  • The same idempotent work as the hourly job, so pressing it twice changes nothing.

3 · functions

Data privacy & retention

Keep personal data to what the work needs, and delete it when it is due. Everything stays in Forge storage for your site.

Retention period

No issue changes

An optional setting that deletes completed, cancelled and declined absences a set number of days after they ended.

What you get

  • Any period from 0, which keeps everything and is the default, up to 3,650 days.
  • Checked daily. Older change-history entries follow the same period.

Safeguards

  • Pending, approved and active absences are never deleted by retention, nor any absence that still has issues to hand back.
  • Never touches issues: they stay with their current assignee.

Delete all data of a person

No issue changes

For data-subject requests: an administrator picks a person and, after a confirmation, deletes what the app stores about them.

What you get

  • The absences they requested are deleted, including reason and type.
  • References to them in other people’s absences, the approver pool and teams are removed; their change-history entries show “Deleted user”.
  • A result with the number of absences deleted and records anonymised.

Safeguards

  • Jira administrators only, re-checked on the server. Works with or without an active subscription.
  • Does not change Jira: issues, comments, Jira groups and Atlassian Teams are left as they are.

Closed-account deletion

No issue changes

Once a week the app reports the account IDs it stores to Atlassian, as Atlassian requires, and deletes the data of every account reported as closed.

What you get

  • The same deletion as “Delete all data of a person”, with no action needed from your administrators.

Safeguards

  • Uses only Atlassian’s own personal data reporting service; nothing leaves Atlassian.
  • Runs regardless of the subscription.

A closer look

What it looks like in Jira

Request time off where your profile lives

The personal settings page holds the request form and your own list of absences with their status and the approver’s note.

  • Absence type, start and end date, optional substitute, optional reason.
  • Cancel your own request; see straight away if some issues could not be handed over.
Personal settings page: the request form with type, start date, end date, substitute and reason, above the list of the user’s own absences with their status.

An approval queue for the people who decide

Approvers see the pending requests routed to them and approve or decline each one, with an optional note for the requester.

  • Routed to a team’s own approvers, or to the sitewide pool.
  • Deciding your own request is refused on the server.
Approval queue on the app’s global page: pending absence requests with requester, type, dates and substitute, each with approve and decline buttons.

Who is away, at a glance

The Team tab shows a month calendar of absences beside a detailed list with type, dates, status and substitute.

  • Sensitive types appear to others only as “Absent”.
  • Reasons are not shown unless an administrator opts in.
  • Who sees whose absences is a setting: all users, the same team, or approvers only.
Team calendar: a month grid with absences per day, and a list of upcoming and ongoing absences.

The hint on the issue

When an issue’s assignee is currently away, the issue view shows until when, and who is covering. When they are present, it shows nothing.

Jira issue view with the out-of-office panel: absent until a date, covered by a named substitute.

One settings page for administrators

Absence types, approvers and teams, the projects the app works in, reassignment policy, reference timezone, visibility, the warning comment, data & privacy and a change history.

  • Jira administrator permission re-checked on the server for every change.
  • Safe defaults, so the app never blocks Jira before it is configured.
Admin settings page with sections for approvers, teams, absence types, substitute coverage, calendar, reason visibility and notifications.

Limits and fixed rules

What the app enforces regardless of configuration. Everything else is a setting.

RuleValue
Reason text1,000 characters
Approver note500 characters
Length of one absence366 days, every calendar day counts
Half daysOnly at the two ends of an absence
Public holidaysUp to 200, entered per year
People per JQL resultUp to 1,000
Change history shown100 most recent
Warning commentsOnce per issue and absence, in selected projects
Coverage jobHourly, or on demand
Projects coveredOnly those selected
Issues movedOpen issues only, up to 5,000 per absence
Atlassian Team membersKept for at most 15 minutes
Retention period0 (keep) to 3,650 days
LanguagesEnglish and German

Clear boundaries

What the app deliberately does not do

  • No blocking of assignmentsForge has no hook that runs before an assignment is saved. The app warns just after, and says so.
  • No instance-wide reassignmentCoverage and warning comments run only in the projects an administrator selected, and coverage only where the absent person may assign issues. With none selected, nothing is reassigned and no comment is posted.
  • No guessed managersJira has no manager field. Approvers are configured: a pool, teams or Jira groups.
  • No approving your own absenceNot even as a pool member or administrator; checked on the server.
  • No reasons on issuesThe hint and the warning comment show the return date and the substitute, never why someone is away.
  • No e-mails, no leave balancesIt sends no notifications about requests or decisions, and it is not an HR system: no allowances, accruals or remaining days.
  • No changes to Atlassian TeamsLinked teams are read, never edited.
  • No data leaving AtlassianNo external calls, no analytics, no sub-processors.

Plan the next holiday season before it starts

Set up absence types, approvers and one covered project in about 10 to 15 minutes. Jira keeps working while you do.

Get it on the Marketplace Documentation