Privacy Policy — Support Attachment Sync for Jira

Last updated: 6 August 2026 Provider: IDEAL WORKS (Japan) Contact: support@conduitworks.dev

1. Scope of This Policy

This Privacy Policy describes how the Atlassian Forge app Support Attachment Sync for Jira (the "App"), published by IDEAL WORKS (the "Provider", "we", "us"), handles data.

The App links Intercom customer support conversations to Jira issues and synchronises attachments from Intercom — for example screenshots, images, and videos sent by end customers — into the linked Jira issue as native Jira attachments.

The App is built on the Atlassian Forge platform and runs entirely on Atlassian's infrastructure. The Provider does not operate its own servers, databases, or hosting environment for the App.

This policy covers only the App. It does not cover Atlassian's own products and services, Intercom's services, or any other software you use.

2. Data the App Stores

The App stores the following in Forge key-value storage, within the Atlassian environment associated with your Jira Cloud site.

Synchronisation records contain, for the most recent sync of each issue:

• attachment file names and sizes in bytes
• the number of files detected, synced, skipped, and failed
• the reason each file was skipped (already present in Jira, or larger than the size limit)
• error messages returned by the Jira or Intercom API, stored verbatim for diagnosis
• the sync state (running, success, partial, error) and start/finish timestamps

Two consequences are worth stating plainly:

• File names are chosen by the person who uploaded the file. A customer may name a file in a way that reveals personal information (for example passport-scan.pdf). Such names are stored as part of the sync record.
• Error messages come from upstream APIs and are stored without modification. They may contain identifiers echoed back by Jira or Intercom.

Data in transit

When a synchronisation runs, attachment content and the conversation data needed to locate it pass through the App's execution context in memory only. This content is not written to the App's storage and does not persist after the operation completes.

The issue panel reads Intercom on every view

Separately from synchronisation, the Jira issue panel fetches the linked conversation from Intercom each time the panel is displayed, and shows its state and attachment metadata (file name, size, content type) to the Jira user viewing the issue. This metadata is not stored, but it is visible to any Jira user who can view that issue.

Webhook endpoint

The App exposes a Forge web trigger URL that receives notification payloads from Intercom. This URL is reachable without authentication, so every payload is verified by HMAC-SHA1 signature before anything else happens (see §4). Verified payloads are parsed in memory to extract the conversation ID and are then discarded — only the conversation ID and the linked Jira issue key are passed to the App's internal queue.

Jira permissions requested

The App requests these Jira scopes and no others:

• read:jira-work
• write:jira-work
• storage:app

The App does not request Jira administrator permissions, nor permission to modify project configuration.

External endpoints

The App communicates only with the following hosts, as declared in its Forge manifest:

• api.intercom.io
• *.intercom-attachments-1.com through *.intercom-attachments-5.com
• *.intercomcdn.com
• *.intercomassets.com

3. Data the App Does Not Store

• Attachment file content. Files are retrieved from Intercom and passed to Jira. The App keeps no copy.
• Conversation message bodies. The text of customer and teammate messages is never written to the App's storage.
• End-customer contact details (email addresses, names, phone numbers) as such. Note the qualification in §2: a file name chosen by a customer may itself contain personal data, and that name is stored.
• Jira user information.

The App does not transmit any of this data to the Provider, and the Provider has no facility to receive it.

4. Where Data Is Stored and How It Is Protected

• All App data is stored in Atlassian Forge storage, inside Atlassian's cloud infrastructure for your Jira Cloud site. The Provider does not hold a separate copy.
• Credentials (the Intercom access token and client secret) are stored exclusively using Forge's encrypted secret storage.
• Incoming webhooks are verified with HMAC-SHA1 over the raw request body (X-Hub-Signature), keyed with your Intercom client secret. A payload whose signature does not match is discarded without being acted on, and the rejection is recorded so an administrator can see it on the settings screen.
• The same applies when no signing secret has been configured: the payload is discarded.
• The endpoint answers every request with HTTP 200, including ones it discards. This is deliberate: Intercom stops delivering notifications for 15 minutes after repeated error responses, which would strand an administrator who is still finishing setup. The status code grants nothing — a payload that fails verification is never processed.
• The App's Forge runtime authenticates to Jira through the Forge platform's app authentication, and to Intercom with a bearer token. No Basic authentication is used in the deployed app. (A Basic-auth Jira client exists in the repository for local development scripts only; it is not reachable from any Forge handler.)
• Access to stored data is governed by the Forge platform's isolation model. Data belonging to one Jira Cloud site is not accessible from another.

5. Disclosure to Third Parties

The App transfers data only between the two services it exists to connect:

• Intercom — to authenticate, receive webhooks, and retrieve attachments.
• Atlassian (Jira Cloud) — to write attachments to issues and to store the App's own data.

The App sends no data to the Provider, to analytics or advertising services, or to any other third party. We do not sell, rent, or trade any data.

We may disclose information only where required by applicable law. Because the Provider has no access to data stored by the App, such a request would in practice need to be directed to Atlassian or Intercom as the parties actually holding the data.

6. Data Retention and Deletion

• Stored data (credentials, mappings, and sync records) is retained for as long as the App remains installed on your Jira Cloud site.
• Disconnecting Intercom. You can remove the stored access token and client secret at any time from the App's configuration screen in Jira. This remains available even when the stored token has expired or been revoked. Disconnecting removes both values together — after reconnecting you will need to save the signing secret again.
• Uninstalling the App. The App itself performs no deletion on uninstall. Removal of its Forge storage is handled by the Atlassian Forge platform according to that platform's own data lifecycle, which the Provider does not control. If you want credentials removed at a specific moment, use Disconnect before uninstalling.
• Attachments already synchronised. Files written to Jira issues become ordinary Jira attachments and are thereafter under your control as the Jira administrator. Uninstalling the App does not remove them; delete them in Jira if required.
• Because the App stores no attachment content and no conversation bodies, there is no separate content retention period.

7. Role Under the GDPR

• You (the Atlassian customer) are the data controller. You decide which Intercom conversations are linked to which Jira issues, and therefore which attachments are synchronised.
• IDEAL WORKS acts as a data processor for any personal data processed through the App, and processes it solely on your instructions — namely the configuration and linking actions you perform within Jira.

The App is designed to minimise processing: it stores no attachment content and no conversation bodies, and the Provider has no access to data held in your Forge storage.

Data subject requests. Because the Provider holds no customer data, requests from data subjects (access, erasure, rectification, restriction, portability, or objection) should be directed to you as the controller and fulfilled within Jira and Intercom. We will provide reasonable assistance if you contact us at support@conduitworks.dev.

International transfers. Where App data is stored is determined by the Atlassian Forge platform and your Jira Cloud site's configuration. Attachment retrieval involves connections to the Intercom endpoints listed in §2.

8. Sub-processors

Both are services you already have a relationship with as a condition of using the App. We will update this section if any additional sub-processor is introduced.

9. Changes to This Policy

If this policy changes materially, we will update the "Last updated" date above and publish the revised policy at the URL listed on the App's Atlassian Marketplace listing.

10. Contact

IDEAL WORKS Email: support@conduitworks.dev