Last updated: 20 August 2026 (§14: a refused sync gives one message whatever the reason; oversized files are skipped, not reported as a connection error; the connection message does include the error text)
Processor: IDEAL WORKS (Japan) — "we", "us", "the Processor"
Contact: support@conduitworks.dev
You — the Atlassian customer who installs the App on your Jira Cloud site — are the data controller. You decide which Intercom® conversations are linked to which Jira issues, and therefore which attachments are processed.
IDEAL WORKS is the data processor. We process personal data only to provide the App.
This agreement applies from the moment you install the App and for as long as it remains installed. It supplements, and does not replace, the Atlassian Marketplace Terms of Use.
| Subject matter | Copying attachments from an Intercom conversation into a linked Jira issue |
| Duration | For as long as the App is installed on your site |
| Nature and purpose | Retrieval, transfer and storage of attachment files and the metadata needed to locate them |
| Types of personal data | Attachment file content (in memory only, not retained); attachment file names and byte sizes; Intercom conversation identifiers; Jira issue keys; error text composed by the App, which may embed a message returned by Jira or Intercom |
| Categories of data subjects | The end customers who contacted your support team, and the teammates who replied |
Two things worth stating plainly. Attachment file names are chosen by whoever uploaded the file, so a customer may name a file in a way that reveals personal data. And error text from upstream APIs is stored as returned, so it may echo identifiers. Both are covered by this agreement. See the privacy policy §2 for the full storage inventory.
We process personal data only on your documented instructions. Your instructions are the configuration and linking actions you perform inside Jira: connecting an Intercom workspace, linking a conversation to an issue, running a sync from the issue panel, and the automatic sync that a signature-verified Intercom notification triggers on a conversation you have already linked.
We do not process the data for our own purposes. We do not sell, rent, share or trade it, and we do not use it to train any model.
If we were ever required by law to process it otherwise, we would inform you before doing so unless that law forbids the notification.
If we believe an instruction of yours infringes the GDPR or other data protection law, we will tell you immediately and may pause the processing concerned until it is resolved (Article 28(3), final paragraph). In practice the instructions this App can carry out are narrow — connect a workspace, link a conversation, sync attachments — so we expect this to be rare, but the obligation stands regardless.
IDEAL WORKS is a sole proprietorship. One person has access, and that person is bound by confidentiality as the owner of the business. There are no employees, contractors or subcontractors with access to your data.
The App runs entirely on Atlassian Forge. We operate no servers, databases or hosting of our own, so there is no infrastructure of ours for an attacker to reach.
kvs.setSecret).What we do not have. No SOC 2, no ISO 27001, no penetration testing programme, no bug bounty. We state this plainly rather than imply otherwise. If your procurement requires any of these, we are not yet a fit.
We engage one sub-processor: Atlassian Pty Ltd, which hosts the App and stores all App data via Atlassian Forge and Jira Cloud.
Intercom, Inc. is not our sub-processor. Intercom is a system you already operate under your own agreement with Intercom. The App reads from it using credentials you supply, at your direction.
We will give you at least 30 days' notice before adding or replacing a sub-processor, by updating this page and its "Last updated" date. If you object, you may uninstall the App; because we hold no data of yours outside Atlassian, uninstalling ends the processing.
Any sub-processor we engage is bound by data protection obligations no less protective than those in this agreement, imposed by written contract, and we remain fully liable to you for its performance of those obligations (Article 28(4)). For Atlassian Pty Ltd that contract is the Atlassian Marketplace Partner Agreement together with Atlassian's own data processing terms, which we accept as a condition of distributing the App.
We hold no copy of your data, so requests from data subjects are fulfilled by you as controller. Where the data lives determines how:
If a Jira issue is deleted before it is unlinked, the App's record for that issue is left behind and can no longer be reached from the panel. What happens to it after you uninstall follows the Atlassian Forge platform's own data lifecycle, which we do not control and do not perform ourselves — see §9. The only control that erases such a record on demand is Unlink, used before the issue is deleted. After that neither the App nor we have a route to it, so we cannot delete one individually; write to support@conduitworks.dev if you need to discuss such a record and we will tell you exactly what remains.
We aim to respond to a request for assistance within 5 business days. That is a target rather than a service level agreement; the App is sold without one (see §8).
Breach notification. If we become aware of a personal data breach affecting your data, we will notify you at the email address registered as your Marketplace contact without undue delay and in any event within 72 hours — the period Article 33 sets for notification to a supervisory authority — with what we know: what happened, which categories of data are affected, the likely consequences, and what we are doing about it. This is a target we intend to hold, not a service level agreement; the App is sold without one, and we are one person who does not staff nights or weekends.
Because we operate no infrastructure, the realistic breach vectors are limited to a compromise of the App's own code or of the credentials you stored. We will say so honestly rather than speculate.
Impact assessments. We will provide the information you need for a DPIA. Most of it is already in the privacy policy and in §5 above.
Your choice, at the end of the provision of services. Article 28(3)(g) gives you the choice between deletion and return. Exercise it by telling us at support@conduitworks.dev which you want, and we will do it. In practice both are already satisfied by the controls above, because we hold no copy of your data outside your own Atlassian site: Disconnect deletes the stored credentials, Unlink deletes the App's own records for an issue, and everything else is data that is already yours, in your Jira site, and never left it.
Existing copies. We keep no copies elsewhere — no vendor-side database, no backups, no exports. The only Provider-visible trace is the diagnostic log described in the privacy policy §2, whose retention is set by the Atlassian Forge platform and not by us. We cannot delete platform logs on demand and we do not claim we can.
We state the uninstall behaviour as it is rather than promising a deletion we do not perform.
We will make available the information needed to demonstrate compliance with this agreement, and will respond to reasonable written questions at support@conduitworks.dev.
We do not hold third-party audit reports. Where you would normally rely on one, the substitute we can offer is that the App's behaviour is verifiable from the outside: the permissions it requests are declared in its Atlassian Marketplace listing, and the hosts it contacts are declared in its Forge manifest and listed in the privacy policy.
Audits and inspections. Article 28(3)(h) requires more than answering questions, so to be explicit: we allow for and contribute to audits, including inspections, conducted by you or by an auditor you mandate. Ask at support@conduitworks.dev. Because we operate no infrastructure of our own — the App runs entirely inside Atlassian Forge and we hold no data outside your Atlassian site — there is no facility of ours to inspect. What an audit can cover is the App's source-level behaviour, its declared permissions and egress hosts, and our answers about how it handles data. We will make ourselves available for that at reasonable notice and no more than once a year unless a security incident makes a further audit necessary. Infrastructure and platform controls are Atlassian's, and their own audit reports cover them.
If your organisation requires its own DPA, send it to us. We would rather sign a reviewed agreement of yours than insist on ours.
Where App data is stored is determined by the Atlassian Forge platform and your Jira Cloud site's configuration, and it is pinned to your site's region. The Processor is established in Japan, which the European Commission has recognised as providing an adequate level of data protection, so no additional transfer mechanism is required for the limited diagnostic access described in the privacy policy.
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.
This section exists so that this document describes the build currently submitted for Atlassian's review, rather than the version we would like to describe. It is removed when the changes below ship.
A known dependency vulnerability. The build currently under review reaches
linkify-it 2.2.0 transitively through the Atlassian Forge UI packages, which npm audit
reports as high severity. The next release pins it to 5.0.2, which clears every high finding.
Attachment file names are currently passed through as your end customer wrote them (§5, Input validation). The next release strips path separators, control characters and quote characters, and bounds the length, before the name reaches Jira.
Diagnostic logs currently include your Intercom workspace name, recorded once when you connect it, and the error message text returned by Jira or Intercom when a call fails. The next release reduces both to status codes and error class names. This is described as it stands today in the privacy policy, §2.
Intercom's EU and Australia regions are not supported by the current release, which connects to Intercom's US endpoints only. Support for both is written and ships next.
The panel never stops promising retries. When a sync has failed attachments the panel says the failed ones will be retried automatically. The current release keeps saying that after the retries have been exhausted. The next release says so instead.
Every sync that stops part-way blames the connection. When an error aborts a whole sync, the current release shows Sync failed (the error text). Check the connection in Jira settings → Apps. The error text itself is included, so you are not left with nothing — but the advice is the same whatever went wrong, including causes that have nothing to do with the connection, such as the issue having been deleted or the app losing access to it. The next release gives guidance per cause. A file above your site's attachment limit does not take this path: it is counted under skipped, as described in the entry above, and individual file failures are reported as N synced, M failed rather than as a connection error.
Connecting Intercom can misdiagnose a rate limit as a missing permission. If Intercom rate-limits or errors during the permission check, the current release reports that the token cannot read conversations. The next release reports it as a connection problem.
The egress declaration. The Forge inScopeEUD flag on our egress hosts should read
false, because every outbound call is a body-less GET and no Atlassian end-user data
leaves. The build under review omits the field, so it declares the platform default, true,
which claims more than the App does. The next release sets it explicitly on every host.
A failed queue submission is not retried, and can silence the webhook. When the webtrigger cannot hand a notification to the internal queue, the current release lets the error escape and answers with a non-200. Intercom then discards every notification to that endpoint for fifteen minutes, so automatic syncing stops with nothing shown on the settings screen. The next release catches the failure, answers 200 and records it. The issue panel's own queue submission has the same gap.
An unsigned request still writes one record, and it turns the settings screen green.
Processing is genuinely gated on signature verification: no unverified request is ever parsed,
matched to an issue, or synced. But in the current release a request that carries no signature
and an empty body still writes one record to the App's own storage — a timestamp and the label
ping, with nothing taken from the request itself — and the settings screen renders that label
as a green success reading that Intercom reached the endpoint. The webtrigger URL is
unauthenticated by design, so anyone who learns it can send one empty request and replace a
signature-mismatch warning with that green message, which could stop an administrator from
investigating a genuinely wrong secret. The next release records nothing at all for a request
with no signature, and reserves the green state for a test request whose signature verified.
To be precise about what that does not fix: a request carrying a wrong signature still records
a warning state in both releases. That direction is fail-safe, because it tells the administrator
to re-check the secret, but it is not zero unauthenticated writes and we do not claim that it is.
Truncated conversations are only reported after a sync. Intercom does not always return every part of a long conversation. The current release surfaces this in the sync result; it cannot warn before the sync runs. The next release reports it when the panel opens.
A refused sync gives one message, whatever the reason. When the panel refuses to start a sync, the current release shows "Could not start the sync." and nothing else. The reason is known internally — no active licence, insufficient Jira permission, no Intercom token stored, no conversation linked — but the current release discards it before the panel is drawn, so a trial that has ended looks exactly like a permission problem. The next release shows the reason. Until then, if that message appears, check the licence under Jira Settings > Apps > Manage your apps first, then whether you can add an attachment to that issue by hand.
Some attachments cannot be fetched. Intercom serves attachment files from a pool of hosts, and the current release declares only part of that pool as a permitted destination, so a file can be refused before it is retrieved. The next release declares the full set.