Privacy and Security
Out of Office Assistant is an Atlassian Forge app. Its code runs on Atlassian's infrastructure and the data it keeps is held in Atlassian's Forge storage, provisioned for your installation, not in a database operated by resolution. That is what the move to Forge changed: the Connect version ran on a separate application host with its own database, and neither is part of how the app works now.
What you approve at installation
The app declares a fixed set of Jira scopes and a fixed set of external domains. A Jira administrator reviews and approves both when the app is installed, and again if a later version changes them. Nobody without Jira administration rights can install the app or widen what it may reach.
The external domains are fixed by the app and shown to you before you approve them. They cover the Atlassian platform services the app runs on, and one domain for each integration provider: login.microsoftonline.com and graph.microsoft.com for Office 365, *.googleapis.com for Google Calendar, slack.com for Slack and api.tempo.io for Tempo. Connecting an integration later does not raise a new consent prompt, because the domain was already approved at installation.
Atlassian Administration > Connected apps > Out of Office Assistant names every one of them under Data management, and lists the Jira permissions the app holds under Authorization.
What the app stores
The app keeps what it needs to evaluate rules and to reach the services you connect:
Out of office rules: the period they run for, the spaces or JQL filter they cover, the coverers and approver coverers they name, and their reply and mention settings.
Templates, and the settings an administrator configures under App Settings, including the Space Admin and Out of Office Admin assignments.
One connection record for each connected integration, holding the credential the app uses to call that service.
REST API tokens, with their description, scope, expiry and last access time.
A reassignment log of the work items a rule handed over. Each entry carries the work item key, its summary, its status, when it was last edited, its Reporter and its Assignee, and the trigger that moved it, which reads
RULEfor a rule and records a bulk assign separately. Reporter and Assignee name people, so this log holds personal data; it is readable by the person the rule belongs to and by the admins described below.
What each integration is granted
Every integration is connected deliberately, by an administrator for the whole site or by the person who owns it, and can be disconnected from the same screen. Permissions and Access Requirements covers where each is connected and what kind of account it needs.
Integration | Access granted |
|---|---|
Office 365 (Outlook) | OAuth 2.0: |
Google Calendar | OAuth 2.0: |
Tempo | An API token issued in Tempo and held by the app |
Slack | Authorisation of the Slack app in your workspace |
The Microsoft and Google grants are read grants: they let the app read the Outlook automatic-reply setting and your Google Calendar entries, and neither permits a write to your mailbox or calendar. offline_access refreshes the app's own token and reaches no further data.
How long it is kept
A rule and its reassignment log are removed on the same schedule. For 30 days after a rule ends it stays in the list whether or not it reassigned anything. Between 30 and 180 days only rules that actually reassigned work items are kept, so those items can still be reclaimed. After 180 days everything is deleted, and deleting a rule deletes its reassignment log with it.
resolution's data processing statement at resolution.de/go/dps covers everything else, including how a request to see or erase data is handled.
What you can switch off
Three vendor-facing data flows are Atlassian controls rather than app settings. An administrator turns each on or off on the same Connected apps screen, and all three are on by default.
Analytics access lets the app send usage data that tells us which parts of it are used.
Logs access shares the app's log activity with us for up to the past 60 days, which is what lets support diagnose a problem you report. You can download a copy of the logs from the same screen.
Custom metrics access shares app monitoring data.
Logs can carry Atlassian account IDs, work item keys and error detail, and are used to diagnose problems you report. Switching any of the three off does not change how the app works for your users.
Who can see an absence
Inside Jira an absence is not private, but it is not site-wide either. One person sees another's out of office data where the two share a space: Team Availability shows that person's status - AVAILABLE, LEAVING SOON or OUT OF OFFICE - and the work item context panel shows the same for an item's assignee. Jira admins and Out of Office Admins see every user's data.
Team Availability therefore lists the people who share at least one space with you rather than everyone on the site, and its space filter offers only your own spaces. Someone with no space in common with you neither appears there nor sees you. A licensed user who is not an administrator also has no App Settings tab. Scoping a rule to certain spaces changes which work items it acts on, not who can see the status: there is no view-only role and no setting that hides one colleague from another inside a shared space.
Outside your Jira licence, the one place the app shows an absence is the Jira Service Management customer portal, and only for the spaces an administrator selects there. That panel carries the agent's status and how long the absence lasts, and nothing else - see Agent Availability Display in JSM Customer Portal.
External access through the REST API
Anything outside Jira that drives the app does so with a token created under App Settings > Rest API Permissions. Scope decides reach: PERSONAL covers only its owner's rules, ADMIN covers every user's. Creating a token, restricting who may create one, and the endpoints it can call are on REST API Endpoints Documentation.
An ADMIN token is the widest access the app grants over its own data. Give every token an expiry, and delete tokens whose owner has left.
Related pages
Permissions and Access Requirements - the three app roles, where each is granted, and what each integration requires.
Migrating from Connect to Forge - what carries over from the Connect app, and which credentials do not.
REST API Endpoints Documentation - creating a token and the endpoints it reaches.
Installation and Setup Guide - the install itself, including the approval step.