Privacy Policy — Intercom 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 **Intercom 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.

Data	Purpose	Storage
Intercom access token	Authenticating API calls to Intercom	Encrypted (`kvs.setSecret`)
Intercom client secret	Verifying that incoming webhooks really come from Intercom	Encrypted (`kvs.setSecret`)
Jira issue key ↔ Intercom conversation ID mapping	Determining which issue an attachment belongs to (stored in both directions)	Forge app storage
Synchronisation records	Showing sync status in the issue panel and supporting troubleshooting	Forge app storage

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

Sub-processor	Role
Atlassian Pty Ltd	Hosts the App and stores all App data (Atlassian Forge, Jira Cloud)
Intercom, Inc.	Source system for conversations and attachments, accessed with the credentials you supply

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