Out of Office & Absence PlannerSecurity & privacy
Written for the people who sign off on the app rather than use it: security review, data protection and works councils. Every answer here follows from how the app is built.
The short version
| Question | Answer |
|---|---|
| Where does the app run? | Entirely on the Atlassian Forge platform, inside your Atlassian tenant. There is no vendor-operated infrastructure in the path. |
| Does any data leave Atlassian? | No. The app declares no external endpoints and makes no external network calls. There is nothing to allow-list. The only APIs it calls are Atlassian’s own. |
| Are there sub-processors? | None. No third party receives any data, because no data is sent anywhere. No analytics or telemetry is bundled. |
| Who can see an absence reason? | By default only the requester and an authorised approver. An administrator can opt in to showing reasons in the team view, but never for a type marked sensitive. Reasons are never shown on an issue and never written to logs. |
| Is “sick” visible to colleagues? | No. For a type marked sensitive, the team view shows others only “Absent”. This is enforced on the server. |
| Who sees whose absences? | An administrator chooses: all Jira users, members of the same team, or approvers and admins only. The person, their responsible approvers and Jira administrators always see it. Enforced on the server. |
| Can personal data be deleted? | Yes. An administrator can delete all data of a person in one step, also without an active subscription. An optional retention period deletes finished absences, and the data of accounts Atlassian reports as closed is deleted every week. |
| Is there a background process? | Yes, four: an hourly coverage job that starts and ends absences and reassigns issues only in the projects an administrator selected, a trigger on assignee changes for the warning comment, a daily retention job, and a weekly personal-data report to Atlassian. |
| Runs on Atlassian? | The app is eligible for Atlassian’s Runs on Atlassian programme, as a consequence of the answers above. |
Data residency
Data residency questions are usually about where a vendor’s servers are. This app has none. It reads and writes your Jira through Atlassian’s own APIs, from inside Atlassian’s infrastructure, and keeps absence records and configuration in Forge storage in the same place. The data never moves, so there is no transfer to assess: your Atlassian site’s data residency configuration governs it, exactly as it governs the rest of Jira. Linked Atlassian Teams are no exception: their members are read from Atlassian, inside Atlassian, and kept for at most 15 minutes.
What is stored
People appear as Atlassian account IDs. The one free-text field that may hold sensitive information is optional.
| Data | Personal data? | Retention |
|---|---|---|
| Absence records: requester, approver, substitute and decider account IDs, dates, absence type, status, decision note, the projects coverage may run in, the team the request was routed through | Yes | Until deleted: by an administrator, by the optional retention period, or when Atlassian reports the account as closed |
| Optional free-text reason on an absence | Yes, potentially sensitive (for example sick leave). Length-bounded, never indexed | With its absence record |
| Configuration: absence types, approver pool, teams or their link to an Atlassian Team, covered projects, policy, timezone, visibility, comment language, retention period, toggles | Account and group IDs of approvers and of manually maintained team members | Until you change it; a person is removed when their data is deleted |
| Members of a linked Atlassian Team, read from Atlassian | Account IDs | Expires after 15 minutes; also discarded on every settings save and every deletion of a person’s data |
| Configuration change history: who changed the settings, when, which settings; also that a person’s data was deleted, never whose | The account ID of the administrator. Never the values that changed | Pruned with the retention period; shown as “Deleted user” once that administrator’s data is deleted |
| Coverage bookkeeping: numeric IDs of the issues moved to the substitute | No: issue IDs only | Cleared when coverage ends; only IDs of issues that could not be handed back are kept, so the requester can be told |
| A de-duplication marker on the issue, so the warning is posted only once | No: one internal absence ID | Stays on the issue in Jira |
Logs contain only event names, absence IDs, numeric issue IDs, counts and status codes; never account IDs, names, reasons or issue keys. After uninstalling, Atlassian deletes the app’s storage: it is kept for 28 days, then permanently deleted. Warning comments and the marker live in Jira, not in the app, and stay as part of the issue’s history.
Permissions (Forge scopes)
The app requests ten scopes. None is specific to Jira Service Management, and there is no project-admin, board or dashboard scope. Each is listed with the reason. The two general Jira issue scopes, marked broad, grant more than the app uses; background changes are confined to the projects an administrator selected and in which the requester may assign issues.
| Scope | Why it is needed |
|---|---|
storage:app | Store the app’s own data in Forge storage: configuration, absence records, the change history and the short-lived cache of Atlassian Team members. |
read:jira-workbroad | Find a person’s open issues and read an issue’s assignee and project; verify Jira administrator permission and the requester’s Assign issues permission in the covered projects; the project picker in the settings. |
write:jira-workbroad | Reassign issues to the substitute, hand them back on return, post the warning comment (internal on Jira Service Management requests) and store its de-duplication marker. |
read:jira-user | Look up users and Jira groups for the approver, team and substitute pickers, check whether a substitute is assignable, and resolve the caller’s own group memberships for group-based approvers. |
report:personal-data | Send the weekly report Atlassian requires of apps that store account IDs, so the data of closed accounts can be deleted. |
view:team:teams | Search and read Atlassian Teams, so an administrator can link one of the app’s teams to one and the link is checked on save. |
view:membership:teams | Read the members of a linked Atlassian Team, for approval routing and team visibility. |
read:account | Read a team member’s account ID and account status, so only active accounts count. Nothing else from the profile is read. |
read:app-data:jira | Read the app’s own cached answers for the absence search function, so they can be refreshed. It reaches no customer data. |
write:app-data:jira | Rewrite those cached answers every hour, so a saved filter does not go on matching people who are already back. |
One further manifest permission is not a scope: inline styles for the app’s interface, because Atlassian’s design-system components style themselves at runtime. It grants no data access and adds no egress.
Controls reviewers ask about
| Control | Implementation |
|---|---|
| Identity | Always re-derived from the Forge context on the server, never taken from the request. |
| Administrator actions | Reading and saving settings, searching Atlassian Teams, the change history, running the coverage job and deleting a person’s data re-verify Jira administrator permission on the server. Placement on an admin page is not treated as authorization. |
| Approvals | Only the approver pool, the requester’s own team approvers or a Jira administrator may decide, never the requester. Re-checked against the stored record on every decision. |
| Group-based approvers | Membership is resolved live from the caller’s own account at decision time, so removal from the group takes effect immediately. |
| Probing other people’s records | Cancelling is limited to the owner, and “not found” and “not yours” are indistinguishable. |
| Background reassignment | Runs as the app, limited to the administrator-selected projects in which the requester held Assign issues when submitting the request, checked with their own permissions. Skips issues Jira refuses to assign. |
| Atlassian Teams | Read as the app, because apps cannot read Atlassian Teams on a user’s behalf. Team search is for Jira administrators only and returns names and member counts, never member lists. Members are used only for server-side routing and visibility decisions. A team that cannot be read counts as having no members; teams anyone can join are ignored for visibility. |
| Sensitive absence types | In the team view, the server replaces a sensitive type with “Absent” for everyone except the requester, an entitled approver and Jira administrators, and never returns its reason. |
| Erasure and retention | “Delete all data of a person” for administrators, also without an active subscription; weekly deletion of the data of accounts Atlassian reports as closed; an optional retention period of up to 3,650 days. |
| Customer-facing leaks | On Jira Service Management requests the warning comment is always internal, so a customer never sees an agent’s absence in the portal. |
| Input validation | Every payload is checked for type, length, allowed values, date validity and ID formats. User input is never interpolated into JQL unescaped. |
| Configuration changes | Every save is logged with who and when, and which settings changed, never their values. |
What we do not claim
- No certification is claimed here. If your process requires a specific attestation, ask us and you will get a straight answer about what does and does not exist.
- The app cannot prevent an assignment. Forge offers no blocking hook; the warning comes just after the change.
- Uninstalling does not remove what the app wrote into Jira. Warning comments and the de-duplication marker remain on the issues, under your control.
- The app is not an HR system of record. It records absences to coordinate work in Jira; it does not calculate entitlements, balances or payroll data.
Reporting a security concern
Raise a request in our support portal and say in the subject that it is a security report, or e-mail support@vi2va.de. Please never include private absence reasons, API tokens, passwords or other secrets; we will never ask for them.
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.