This article details the data that is stored in our database for the Microsoft Teams feature. In general, we don’t store actual content from your system(s), but only metadata, settings and similar data. Some of the data is only collected for Jira Cloud systems, but most examples also apply to Jira Server or Jira Data Center systems.
To associate the different entities (like issues & chats) with one another, we store certain kinds of metadata - mostly mappings between two kinds of entities. The examples provided below are not 1:1 representations of the actual database, but show the most relevant information being stored.
When you login with Jira & Microsoft Teams in our app, we’ll associate the two account with another. This is necessary, so we can impersonate you correctly, e.g. when posting a reply in a chat from Jira, or when creating a Jira issue from Microsoft Teams. An example dataset looks something like this:
Jira issue / Teams chat & conversation mapping
When you create a new Teams chat from Jira, the chat will show up in the issue. To make this work, we store a link between these two entities, which looks somewhat like this. This information is also used when changes to an issue happen, so we can send the update to Microsoft Teams accordingly.
Teams chat id
Jira issue shared chat access
When creating a Teams chat from Jira, a user can allow other Jira users to access the chat in Jira, without actually being a member of the chat. We call this feature “shared chat access”. To support this feature, we have a database table specifying the exact sharing permissions.
Jira instance information
To be able to identify your Jira system correctly, we store certain information about it in our database. For Jira Cloud, this data is provided by Atlassian directly, for Jira Server and Data Center, we provide this ourselves (also see Install the Teams app for Jira Server / Data Center | Initial-configuration).
Shared secret (shortened)
Teams bot membership
When a user installs the Microsoft Teams app, Microsoft notifies our servers about this. To be able to send notifications to a certain Teams user or channel, we need to store the identifiers provided to us by Microsoft.
User, project & instance settings
To support certain functions that need to run on our own servers (e.g. for handling certain webhooks), we need certain settings to be present in our database. Which exact settings differs a bit between Jira Cloud and Jira Server/DC, but most apply to both.
Global Jira settings
When a user or an administrator changes a setting (e.g. appearance of the app), we persist this choice in our database as well. This looks something like this:
JSM portal settings
To be able to serve the Jira Cloud JSM poral in Teams, we store the settings in our database.
Portal App ID
Teams user settings
For certain scenarios, we store user settings for each user that has installed the app in Microsoft Teams. Currently, this only includes a flag, that the welcome message has already been sent by the bot, but this might contain additional settings in the future.
Teams user ID
To be able to bi-directionally access Jira & Microsoft Teams, we store user-based and application-based access tokens in our database. These tokens are encrypted at rest and additionally at application level, using industry standards (AES-256). At no time have our employees access to your Jira or Microsoft Teams content. Every access to the secret storage is only allowed for certain core employees and fully auditable. Please also refer to our Security & Privacy docs.