See also the generic overview of our product data flows: Product Data Flows

Overview

Data processing for the email / Outlook add-in feature is a bit more complex than the others, since the Outlook add-in was built when a lot of our customers still relied on Jira Server / DC systems, in combination with a self-hosted Exchange email server. Therefore, the newer features in Jira work very similarly to Teams, whereas the Outlook add-in itself relies much more on direct connections to Jira.

Jira functionality

In general, we have optimized the app to be as integrated with Microsoft 365 emails as possible. The result of this is that the architecture for Jira Cloud & Server / DC is very similar. This is a bit uncommon for the on-premise systems, as traditional apps for these systems are not relying on any cloud service. To provide the same features for Jira Server & Data Center as well, there is currently no other way than using a cloud infrastructure.

Data flow for user interactions

Some of the user interactions from Jira require the involvement of our own infrastructure. When possible (technically and security wise), we still access Microsoft services from Jira via the users browser, instead our servers (Graph API direct access). Examples for user interactions are:

  • Sending or replying to an email from Jira

  • Viewing a linked email conversation in Jira

Data flow for application triggered changes

Some features are triggered without user interaction - like new email notifications. Instead use webhooks to be processed. Email related examples for this are:

  • A new email for a linked conversation is received and the Jira issue watchers are notified

Outlook add-in connection

The Outlook add-in uses different ways to connect to Jira depending on the system and how it is configured. It shows a security indicator on top that explains how it is connected:

Direct connection with COM add-in

When using our COM add-in, it will always use a direct connection. As we are running a program on the local computer, we are not limited by the used browser.

Direct connection Office add-in

SERVER ONLY

The Office add-in only runs in the browser, so we have to respect the given restrictions. Jira does not send CORS headers in a consistent and reliable manner, so we need to rely on some other techniques. In our case we do the trick with an iFrame provided by the Jira app. By embedding it in Jira in Outlook, the Jira system is part of the add-in and it is not cross-domain anymore.

This requires your Jira system to run on https - otherwise we cannot embed the iFrame due to mixed content

The mentioned iFrame is located at

https://your-jira-instance/plugins/servlet/jiraforoutlook/proxy

Connection via our infrastructure

Whenever we cannot use a direct connection, we use our infrastructure to call Jira. This way we can get around a lot of the restrictions for web apps. However, because every request is proxied via our servers, the Jira system needs to be public.

This proxy does not log or store any information, it's just a pass-trough system. Especially in combination with signed OAuth 1a requests, this is very secure because all requests are singed by one-time tokens only valid for a specific URL. No generic access is possible.