RFC-110: Third-Party Cloud Storage Integrations for Jira Work Items

Jira Development Jira Cloud
, ,
1

Project Summary

We’re proposing native integration of Google Drive, Dropbox, and other cloud storage services into the Jira Work Item attachment panel to streamline workflows, reduce friction, and align with user expectations for modern tools.

  • Publish: 21/08/2025

  • Discuss: 04/09/2025

  • Resolve: 11/09/2025

What this RFC is / is not

This RFC is:

  • A proposal to integrate first-party support for Google Drive, Dropbox, and similar services.

  • Focused on the file selection and attachment experience in Jira Work Items.

This RFC is not:

  • A redesign of the entire attachment panel.

  • A replacement for Marketplace apps that offer deeper integrations (e.g advanced previews, workflow automations).

Context & Strategic Alignment

This initiative is part of our broader transformation strategy to simplify workflows for business teams and meet users where they work. By natively supporting popular cloud storage providers, we aim to:

  • Reduce context switching and manual steps for attaching files.

  • Align Jira with user expectations for modern, integrated productivity tools.

  • Empower teams to collaborate more efficiently, especially as remote and hybrid work increases reliance on cloud storage.

Overview

This RFC proposes a unified approach for integrating third-party cloud storage providers (e.g. Google Drive, SharePoint, Dropbox, Box) into Jira Work Items. The goal is to enable users to seamlessly attach, preview, and manage files from these providers directly within the Jira Attachments Panel.

Problem Statement

Currently, Jira users rely on native attachments or ad-hoc links to external files, leading to fragmented workflows and inconsistent user experiences. There is no standardised way for third-party storage providers to integrate with Jira Work Items, limiting discoverability and extensibility for both users and Marketplace App vendors.

MVP Scope & Out of Scope

MVP will include:

  • Integration with Google Drive and Dropbox (with Box and SharePoint as stretch goals or for future phases).

  • File picker experiences for selecting files from connected accounts.

  • OAuth-based authentication for secure connections.

  • Display of attached files in the Attachments Panel, visually distinct from native uploads.

Out of scope for MVP:

  • Real-time collaboration or in-line editing

  • Full redesign of the Attachments Panel

  • Deep syncing or workflow automations

User Flow:

  1. User clicks “Attach” in a Jira Work Item or the ‘Add Attachment’ button that sits under the Attachments Panel.

  2. Dropdown opens with options: “From device,” “From Google Drive,” “From Dropbox.”

  3. If not yet connected, OAuth flow triggers for the selected provider.

  4. User browses and selects file(s) from their cloud storage.

  5. Selected file(s) appear in the attachment section.

f715b1f8-55e7-4204-bc80-0d912a3591eb
f715b1f8-55e7-4204-bc80-0d912a3591eb1280×854 172 KB

Extensibility Opportunities

Marketplace App vendors can:

  • Build custom file-picking experiences.

  • Surface file metadata (for example, last modified, highlights changes) in the Attachments Panel.

  • Implement advanced actions (for example, request access, share, comment) via provider APIs.

  • Track file activity and surface insights within Jira.

Future Plans

  1. Support for Major Cloud Storage Providers:
    We will initially support integrations with Google Drive, Dropbox, SharePoint, and Box, enabling users to attach and manage files from these providers directly within Jira Work Items.

  2. File Picker Experiences:
    Users will be able to browse and select files from their connected cloud storage accounts using intuitive, provider-specific file pickers embedded in the Jira Attachments Panel.

  3. File Previews:
    Attached files from third-party providers will support in-context previews, allowing users to view documents, images, and other supported file types without leaving Jira.

Feedback Needed

We’d love your input on:

  1. Are there other storage providers we should include in MVP?

  2. What technical or security concerns should we anticipate in enterprise environments?

  3. Do you see this reducing reliance on Marketplace apps, or are there features those apps still provide that this doesn’t cover?

Thank you for helping us build a more connected and extensible Jira!

1 Like
2

To comply with data residency requirements, is there an intention for a Jira Admin to be able to restrict the users to only be able to specify or select cloud data storage vendors or locations in specific regions?

2 Likes
3

Do we know yet how the Jira REST attachment API’s would change. e.g. would the new google drive attachments be returned from a get attachments call.

Would the Jira API be able to be used to add/update an external attachment, either uploading new content, or linking to existing content?

Thanks
Chris

4

Just my 2 cent here, first of all it sounds like a great addition to the product but the term “Attachment“ sets expectations and can make things complicated.

  • Attachments are part of the issue. If you are the assignee of the issue, you should be able to access the attachments. Simply think about an external vendor that is supporting in the process and the runbook to solve a P1 is attached..
  • Respecting vs. ignoring source system file permissions
  • Attachments are included in backups to fulfil disaster recovery procedures. Should be included when data is copied to the Sandbox or an environment is merged / splitted across multiple instances.
  • Deleting an attachments would not delete the source. Instead it would be rather just the deleting the reference.

Therefore i would see “attachments“ as part of add a link or call “external attachment“, because it’s just a link / reference and not a real attachment.

Maybe one additional attachment storage provider → Confluence itself instead of just a page link.

5

I would tend to agree with @tied in that the current expectation of the ‘Attachment’ panel is that it is going to be a ‘hard’ file that the user will be able to access. Any other links that are on the Work Item, would be subject to the access controls of the target application.

My initial reaction to this is this is a further pull into duplicating functionality that already exists in the Marketplace. While this could be novel, a quick marketplace search has 25 Google Drive, 10 Dropbox, 20 SharePoint, 6 Box, and 13 OneDrive apps that perform some kind of integration/synchronization. Given that each of these services has multiple apps, my feeling is that there are varying opinions on how the integration works. As such, once Atlassian provides first party support, customers are going to want more advanced support out of this rather than having to leverage both Atlassian First Party support for some features and then 3rd party support for other operations. More or less the idea of a single provider for a complete feature.

From an enterprise POV, depending on their search stance, they may or may not want to allow integration to these products or even offer the options to use them as it opens up the temptation for users to use them thinking they are approved since it’s in the UI when the product may not be approved for use. The current model of being able to get Marketplace apps that target specific providers seems ideal.

I do like the idea of being able to provide a centralized common user experience for this kind of operation. I feel like the extension points that are being called out here should be published as Forge modules so that the current Marketplace app vendors can extend and be able to provide a more common operational model/user experience.