Last updated: 20 August 2026 (that write:jira-work is broader than the App uses; the one delete call the App carries but never invokes, and the full list of Jira endpoints it does touch; the webhook case that does not answer 200)
Provider: IDEAL WORKS (Japan)
Contact: support@conduitworks.dev
This policy is about the App. The website you are reading it on, conduitworks.dev, is a
separate thing, and two facts about it are worth stating here rather than leaving you to find
them.
Neither of these has any connection to the App or to your Jira and Intercom® data. The App runs inside Atlassian Forge and never contacts this website.
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.
Which attachments. The App copies every attachment on the linked conversation: the ones on the opening message and the ones on each reply. It does not distinguish who attached a file, and it does not skip internal notes. A file your teammate attached to a note that the end customer cannot see is copied to the Jira issue like any other, where anyone who can view that issue can open it. If your team uses internal notes for material that should not reach the issue's audience, take that into account before linking a conversation.
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.
Responsibility for your data. IDEAL WORKS — and not Atlassian — is responsible for the privacy, security, and integrity of any end user data processed by IDEAL WORKS or by this App. Atlassian provides the Forge platform on which the App runs, is not a party to this policy, and does not control how the App handles that data. Questions, complaints, and data protection requests concerning this App should be sent to support@conduitworks.dev.
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 |
| Last webhook outcome | Telling an administrator on the settings screen whether notifications are arriving. Contains a timestamp and a result category only (for example "queued", "signature did not match"). No conversation content. | Forge app storage |
Synchronisation records contain, for the most recent sync of each issue:
Two consequences are worth stating plainly:
passport-scan.pdf). Such names
are stored as part of the sync record.http_403
instead of any text.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.
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 Jira users who hold the Create attachments permission on that issue — the same permission the panel checks before it renders anything at all.
What that permission does and does not limit. The check is on the Jira issue, not on the conversation. The App holds no mapping between a Jira account and an Intercom teammate, so it cannot tell whether the person asking is entitled to a particular conversation. A user who holds Create attachments on any issue can enter any conversation id from your connected workspace — provided it is not already linked to another issue — and pull that conversation's attachments onto an issue they can see. Grant Create attachments on projects where this panel is available only to people you would allow to read the workspace's support attachments.
The App exposes a Forge web trigger URL that receives notification payloads from Intercom. This URL is reachable without authentication. A request carrying no signature and no body is Intercom's connectivity check: it is answered with 200 and noted as "something reached this endpoint", and nothing else is done with it. Once a signing secret is stored, every request that carries a payload is verified by HMAC-SHA1 signature before the payload is read (see §4). Before a secret is stored there is nothing to verify with, so payloads are discarded unread and only the fact that something arrived is recorded. 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.
The App requests these Jira scopes and no others:
read:jira-workwrite:jira-workstorage:appThe App does not request Jira administrator permissions, nor permission to modify project configuration.
write:jira-work is broader than what the App uses, and the Marketplace listing says so
in Atlassian's words. On the listing's Privacy & Security tab that scope is described as
"Create and edit issues in Jira, post comments as the user, create worklogs, and delete
issues." Atlassian does not offer a narrower scope for adding an attachment to an issue, so
granting it is the only way to do the one thing this App does with it. The App uploads
attachments. It does not delete issues, does not post comments, does not create worklogs and
does not edit issue fields — there is no code in it that calls those endpoints.
One qualification, because it is the kind of thing you would rather find here than in a code
audit: the App does contain one delete call, DELETE /rest/api/3/attachment/{id}, and it is
in the module Forge actually loads, so an auditor will find it there. It exists so our own test
harness can remove the files it uploaded during testing, and no path the App runs invokes
it — the only caller anywhere in the repository is a test file, which is not part of the
deployed bundle. Every other Jira endpoint the App touches is a read or the attachment upload:
/rest/api/3/myself, /rest/api/3/mypermissions, /rest/api/3/attachment/meta, the issue
itself, and POST /rest/api/3/issue/{key}/attachments. There is no call to a comment, worklog
or issue-update endpoint anywhere in it. It will be removed from the shipped code in the next release. The
protection you have until then is the scope description on the listing, this statement, and the
fact that the call is unreachable from the App's own entry points; if that is not enough for
your organisation, that is a reasonable place to stop.
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.comNothing from Jira is sent to those hosts. Every outbound request the App makes is a GET
with no request body. Requests to api.intercom.io carry the Intercom access token you
supplied and an Intercom conversation ID. Requests to the attachment hosts carry neither —
the download URL is a signed URL issued by Intercom, and the token is never attached to it.
No Jira issue key, no Jira user or account identifier, and no attachment content is ever sent
outward — attachments travel in
one direction only, from Intercom into your Jira site.
What that means for the Forge inScopeEUD declaration on those hosts: the accurate value is
false. The build currently under review omits the field on its egress hosts, so it declares
the platform default, true — which over-declares rather than under-declares, but still does
not match the behaviour described above. The next release sets inScopeEUD: false explicitly on
every egress host. If a future version ever writes back to Intercom, that declaration will change with it.
Separately from the storage described above, the App writes diagnostic entries through the Atlassian Forge logging platform. These entries are visible to the Provider, which is the one place the Provider can see anything relating to your use of the App. They are used only to diagnose faults.
A log entry can contain:
A log entry does not contain attachment content, conversation or message text, Jira user or account identifiers, the access token, or the client secret.
We state the last two items plainly rather than claim a narrower log than we keep. The App never writes an attachment file name to a log deliberately — but an error message returned by Jira or Intercom can quote one, and in this version that message is recorded as returned, so we do not claim that file names never appear. An error message returned by an upstream API is written by that API, not by us, and in principle it can quote an identifier. We do not send it anywhere else, and we are working to reduce the logs to status codes and error classes alone.
Retention of these entries is determined by the Atlassian Forge platform, not by the Provider.
None of the items listed above is written to the App's storage, and none of them reaches the Provider. The one thing the Provider can see is the diagnostic log described in §2, whose contents are enumerated there; the Provider has no other route to data held by the App.
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.Everything the App stores is held in Forge hosted storage (the Forge Key-Value Store) and is therefore in scope for Atlassian data residency: it is pinned to the same region as your Jira Cloud site. That covers every item listed in §2 — the Intercom access token, the Intercom client secret, the issue ↔ conversation mapping, the synchronisation records, and the last webhook outcome.
Out of scope: attachment content and conversation data while in transit between Intercom and your Jira site, which the App does not store (see §2, "Data in transit"), and the App's diagnostic log entries, which the Forge platform holds under its own arrangements. The App uses no Forge Remote backend and operates no storage of its own, so there is no category of stored data outside Forge hosted storage.
The App transfers data only between the two services it exists to connect:
The App sends no data to analytics or advertising services, or to any other third party. We do not sell, rent, or trade any data. The only visibility the Provider has is the diagnostic log described in §2, which the Atlassian Forge platform makes available to us for fault diagnosis — the App does not transmit anything to the Provider by any other route.
We may disclose information only where required by applicable law. Because the Provider has no access to the data the App stores — only to the diagnostic log described in §2 — such a request would in practice need to be directed to Atlassian or Intercom as the parties actually holding the data.
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 terms on which we act as processor — instructions, confidentiality, security measures, sub-processors, assistance with data subject requests, breach notification, and deletion — are set out in our Data Processing Agreement, written to Article 28(3). If your organisation requires its own DPA instead, send it to us.
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. The Provider holds no copy of your data, so requests from data subjects (access, erasure, rectification, restriction, portability, or objection) are fulfilled by you as the controller. Where the data lives determines how:
Attachments already synchronised are ordinary Jira attachments. Handle them in Jira.
Conversation content stays in Intercom. Handle it there.
The App's own records — the issue ↔ conversation mapping and the synchronisation record, which includes attachment file names — live in Forge storage for your site. Use Unlink on the issue panel to delete both for that issue. Unlink is the only control that erases the App's own record; a linked issue cannot be re-pointed at another conversation without unlinking it first, so there is no second route. Disconnect on the settings screen removes the stored credentials only; it does not clear sync records.
If the Jira issue is deleted before it is unlinked, the App's record for that issue is left behind in Forge storage and can no longer be reached from the issue panel. Neither the App nor the Provider has a route to that record; what happens to it after you uninstall follows the Atlassian Forge platform's own data lifecycle, which the Provider does not control and does not perform — see §6. The only control that erases such a record on demand is Unlink, used before the issue is deleted.
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.
California (CCPA/CPRA). IDEAL WORKS is a sole proprietorship in Japan and does not meet any of the thresholds that make an entity a "business" under the CCPA. We do not sell or share personal information, and we receive no consideration for any personal information processed through the App. If you are a business subject to the CCPA and use this App, the processing described in §2 is carried out on your behalf and at your direction.
| Party | Role |
|---|---|
| Atlassian Pty Ltd | Sub-processor. Hosts the App and stores all App data (Atlassian Forge, Jira Cloud). The App runs entirely inside Atlassian's infrastructure. |
| Intercom, Inc. | Not a sub-processor of IDEAL WORKS. Intercom is a third-party system you already operate under your own agreement with Intercom. The App reads from it using credentials you supply, at your direction. |
The Provider engages no sub-processor other than Atlassian, and operates no servers, databases, or hosting of its own. We will update this section if that ever changes.
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.
IDEAL WORKS Email: support@conduitworks.dev
The Intercom name and logos are the trademarks or service marks of Intercom, Inc. or its affiliates in the U.S. and other countries. Atlassian, Jira and Forge are trademarks of Atlassian Pty Ltd. IDEAL WORKS is an independent vendor and is not affiliated with, endorsed by, or sponsored by Intercom, Inc. or Atlassian Pty Ltd. These names are used only to describe what this App interoperates with.