IDEAL WORKS

We build small, single-purpose integration apps for Atlassian teams.

Support Attachment Sync for Jira

A support agent files a bug from a customer conversation. The engineer picks it up in Jira and finds a description of a screenshot they cannot see.

This app links an Intercom® conversation to a Jira issue and uploads the files the customer sent — screenshots, photos, screen recordings, PDFs, logs — to that issue as native Jira attachments. Automatically when someone replies, or on demand from the issue panel.

Approved by Atlassian and on sale now on the Atlassian Marketplace for Jira Cloud. Support Attachment Sync for Jira — approved 20 August 2026. Install it from there; there is a free trial before you are charged.

What it does not do

• It does not request Jira administration rights, and it does not change project configuration. Requested scopes are read:jira-work, write:jira-work and storage:app.
• It does not store attachment contents or conversation text. Files pass through to Jira.
• It does not write attachment contents, conversation text or your credentials to logs. It does write the Jira issue key, the Intercom conversation id, your Intercom workspace name once when you connect it, and the error text an upstream API returns when a call fails. That error text is recorded as returned, so a file name quoted back by Jira or Intercom can appear in it. The privacy policy lists all of it.

What you need

• Jira Cloud, with site administrator access.
• A paid Intercom subscription. Intercom is a separate product, sold and licensed by Intercom, Inc. under your own agreement with them. It is not included with this app, we do not resell it, and this app does nothing without it.
• An Intercom workspace in Intercom's US region. This version connects to api.intercom.io only. Workspaces hosted in the EU or Australia use different Intercom endpoints and are not supported yet. Regional support is planned.

Size limits, stated plainly

Intercom allows up to 100 MB per file. Your Jira site has its own attachment limit, set per site, and it is often considerably smaller. The app reads both and applies whichever is stricter. Files above that limit are skipped rather than uploaded. The panel shows a skipped count only when nothing else failed in the same sync — if any file failed, this release does not display the skipped count at all.

The open defects that affect syncing

Three. A fix is written for the first two and ships in the next release; the third we found on 18 August 2026 and have not fixed yet.

1. Some attachments are refused before they are fetched.

Intercom serves attachment files from a pool of hosts, and this release declares only part of that pool as a permitted destination. A file served from an undeclared host is refused before it can be fetched, and the panel counts it as failed with a download error — not as skipped.

Files an end customer sent through the Intercom Messenger are the ones to expect this on. Intercom's own integration guidance lists a separate host for Messenger uploads, and that host is not among this release's declarations, so those files are expected to fail consistently rather than now and then. We have not measured which host serves any given file, so we say expected rather than certain.

2. Automatic syncing can stop for fifteen minutes at a time. If an incoming notification cannot be handed to the app's internal queue, the endpoint answers with an error and Intercom stops delivering to it for fifteen minutes. Nothing changes on the settings screen while this happens, so the setup still looks healthy.

3. A file a customer sent can be skipped because a similarly named file is already on the issue. To avoid uploading the same file twice, the app ignores a trailing number in brackets when it compares names — screenshot (2).png is compared as screenshot.png. It cannot tell a number it added itself from one a person typed. So if someone has manually attached screenshot (2).png to the issue and a customer then sends a screenshot.png of exactly the same byte size, the app treats them as the same file and skips the customer's one. The panel counts it under skipped, so nothing on screen says which file was dropped. Different sizes are unaffected. The fix is to limit that rule to names the app generated itself.

Those three are the ones that can stop a file reaching your issue. The status page lists a fourth open item that does not: a sync running longer than about two minutes stops updating the panel, while the sync itself carries on. That is why the two counts differ.

Current detail is on the status page, the full list of known limitations is in support, and the items that affect what the app does with your data are in the data processing agreement §14.

About us

IDEAL WORKS is a new, independent vendor and this is a new app. We do not hold SOC 2 or ISO 27001 certification, the app is not Cloud Fortified, and we run no bug bounty. We would rather you decide with that in front of you than discover it later.

For the terms we process personal data under, see the Data Processing Agreement. If your organisation requires its own DPA, send it to us.

Support: support@conduitworks.dev

We aim to reply within two business days. We are one person, in Japan (UTC+9). We are not staffed for nights, weekends or 24/7 coverage, and we do not promise it.

Reporting a bug, and what is already known

There is no public issue tracker. Send bug reports and feature requests to support@conduitworks.dev. One person reads that address.

What we already know to be broken is written above under The open defects that affect syncing, with current detail on the status page. The full list of limitations, including the ones that are deliberate rather than defects, is in support.

Before you buy

Setup needs someone who is both a Jira administrator and able to create an app in Intercom's Developer Hub. It takes about 15 minutes, once. The full procedure is written out in the Setup guide, including how to confirm the connection actually works before you wait for a real customer.