Absence Planner SyncSecurity & 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, and we as the vendor never receive your data. |
| Does any data leave Atlassian? | Only to your own mail system, and only once an administrator connects it. Then names, mailbox addresses and absence dates go to your Microsoft 365 or Google Workspace tenant — the hosts are listed below. Never the absence type, never the private reason. |
| Are there sub-processors? | We engage none. Microsoft or Google process the data as part of the Microsoft 365 or Google Workspace service you already use, under your own agreement with them. No analytics or telemetry is bundled. |
| What does the app read from mailboxes? | For the optional import: the window of a scheduled automatic reply and the start and end of calendar entries marked out of office. Never messages, subjects, bodies, attendees or locations. |
| Whose mailbox can the app write to? | Only a mailbox its owner linked — with a code sent to it, or, if an administrator allows it, through the Atlassian account’s own address within the allowed domains. |
| Where are credentials kept? | In Forge secret storage, write-only: no screen and no API returns a stored client secret or key. Access tokens are kept in memory only and never logged. |
| Is “sick” visible to colleagues? | No. For a type marked sensitive, the team view shows others only “Absent”, enforced on the server. No type is ever sent to a mailbox. |
| Can personal data be deleted? | Yes. An administrator can delete all data of a person in one step — including their mailbox link, and the automatic reply and calendar entries the app wrote — also without an active subscription. |
| Runs on Atlassian? | No, because the app connects to Microsoft or Google. The app itself still runs only on Forge. |
Data residency
The app has no servers of its own. It reads and writes Jira through Atlassian’s own APIs and keeps absence records, configuration and credentials in Forge storage, so your Atlassian site’s data residency configuration governs that data, as it governs the rest of Jira. What the mail integration sends goes directly from Forge to your Microsoft 365 or Google Workspace tenant, where it is stored like any other automatic reply or calendar entry — under the data residency of that tenant. Nothing passes through, or is copied to, infrastructure of ours.
External connections
Every host the app may call, as declared in its manifest. Forge blocks any other. None is called before an administrator connects the mail system.
| Host | Used for | What it receives |
|---|---|---|
login.microsoftonline.com | Microsoft 365: sign-in of the app (OAuth 2.0 client credentials) | The app registration’s id and secret — no end-user data |
graph.microsoft.com | Microsoft 365: e-mails, automatic replies, calendar entries; reading for the import; change notifications | Names, mailbox addresses, absence time windows, e-mail and automatic-reply texts |
oauth2.googleapis.com | Google Workspace: sign-in of the service account (domain-wide delegation) | A signed assertion naming the mailbox the app acts as |
gmail.googleapis.com | Google Workspace: e-mails and the vacation responder | Names, mailbox addresses, absence time windows, texts |
www.googleapis.com | Google Workspace: calendar entries; reading for the import; push channels | Mailbox addresses, absence time windows, calendar-entry ids |
Inbound: Microsoft and Google notify the app about calendar changes through a Forge web trigger. A call is accepted only with the secret of a channel the app opened itself (compared against a stored hash), and it can do nothing but prompt a fresh read of that one person’s calendar.
What is stored
People appear as Atlassian account IDs. Mailbox addresses are stored only for people who linked one.
| Data | Personal data? | Retention |
|---|---|---|
| Absence records: requester, approver, substitute and decider account IDs, dates, absence type, status, decision note, coverage projects, 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). Never sent anywhere | With its absence record |
| Linked mailbox: address, how it was verified, the person’s own switches and automatic-reply text | Yes | Until the person unlinks it, or their data is deleted |
| Pending verification: address and a hash of the code | Yes | 15 minutes |
| Sync and import bookkeeping: the mailbox written to, calendar-entry ids, what was sent, the dates of imported windows | Yes | With the absence; import data on unlink, opt-out or deletion |
| Mail credentials: client secret or service-account key | No | In Forge secret storage until an administrator deletes them |
| Configuration and its change history (who changed which setting, never the values) | Account IDs of approvers and administrators | Until you change it; history pruned with the retention period |
Logs contain only event names, opaque IDs, counts and result codes; never names, addresses, texts, reasons or tokens. After uninstalling, Atlassian deletes the app’s storage: it is kept for 28 days, then permanently deleted. Automatic replies and calendar entries already written stay in the mailboxes, under your control; delete a person’s data beforehand to remove theirs.
Permissions (Forge scopes)
The app requests ten Atlassian scopes. None is specific to Jira Service Management, and there is no project-admin, board or dashboard scope. The two general Jira issue scopes, marked broad, grant more than the app uses; background changes are confined to the projects an administrator selected.
| Scope | Why it is needed |
|---|---|
storage:app | Store the app’s own data in Forge storage: configuration, absence records, mailbox links, sync and import bookkeeping, the change history; credentials in secret storage. |
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. |
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 groups for the pickers, a person’s language for e-mails, and — only if an administrator allows it — the e-mail address Atlassian holds for an account. |
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. |
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. |
read:app-data:jira | Read the app’s own cached answers for the absence search function, so they can be refreshed. |
write:app-data:jira | Rewrite those cached answers every hour, so a saved filter does not go on matching people who are already back. |
In your mail system the app needs, depending on the provider: Microsoft Graph application permissions Mail.Send, MailboxSettings.ReadWrite and Calendars.ReadWrite (limit them to the relevant mailboxes with an Exchange Online application access policy), or Google scopes gmail.send, gmail.settings.basic and calendar.events via domain-wide delegation. The import needs no further permission.
Controls reviewers ask about
| Control | Implementation |
|---|---|
| Identity | Always re-derived from the Forge context on the server, never taken from the request. Self-service mail actions act on the signed-in person only. |
| Administrator actions | Mail settings, credentials, the connection test and every other admin action re-verify Jira administrator permission on the server. Placement on an admin page is not treated as authorization. |
| Mailbox ownership | A random 6-digit code, stored only as a hash bound to account and address, compared in constant time, valid 15 minutes, 5 tries, a new one after 60 seconds. Every stored link is re-checked against the allowed domains at each use. |
| Credentials | Validated, stored with Forge secret storage, never returned. Tokens cached in memory only, never persisted or logged. |
| What is sent | E-mail and automatic-reply texts are built on the server; every inserted value is escaped, subjects are single-line. The absence type and reason are never part of them. |
| Import | Reads only time windows. What the app wrote itself is recognised and never imported back; imported absences are never written back to the mailbox. |
| Public web trigger | Accepts only notifications that carry the secret of a channel the app opened, size-capped; a verified call only queues a fresh read, at most once per person and minute. |
| 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. |
| 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. |
| Background reassignment | Runs as the app, limited to the administrator-selected projects in which the requester held Assign issues when submitting the request. |
| Erasure and retention | “Delete all data of a person” removes absences, mailbox link and the items the app wrote to their mailbox; weekly clean-up of closed accounts; optional retention period. |
| Input validation | Every payload is checked for type, length, allowed values and ID formats; e-mail addresses with a strict, linear-time pattern. User input is never interpolated into JQL or URLs unescaped. |
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 is not “Runs on Atlassian”. Its purpose is to connect Jira with your mail system.
- The app cannot prevent an assignment. Forge offers no blocking hook; the warning comes just after the change.
- One automatic reply per mailbox. Microsoft and Google keep one automatic-reply setting per mailbox. Cancelling an absence switches it off — also one the person set by hand in the meantime.
- Uninstalling does not remove what the app wrote. Automatic replies and calendar entries in mailboxes, warning comments on issues, stay under your control.
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, client secrets, keys, passwords or other secrets; we will never ask for them.
Plan the next holiday season before it starts
Set up absence types and approvers, connect Microsoft 365 or Google Workspace and link a pilot group in under an hour. Jira keeps working while you do.