Privacy

Applies to: Dwell — Cycle Time & Lead Time Chart for Jira.

Every statement on this page describes what the app's code actually does. Where a claim is enforced by an automated test, the test is named. Where something is a limitation rather than a guarantee, it says so.

What the app reads

To compute how long work items take, the app reads, from your Jira site:

• the saved filter you selected, and the JQL it contains. It is read as you each time a chart, drill panel or export is served, because that read is also the permission check described under Who can see a chart below. It is also read as you in the gadget's settings, when you pick a filter and when the settings open with one already chosen, to check whether its results depend on who is viewing it (why); only the names of any such functions, and of the saved filters they were found in, go back to the settings

• every saved filter that filter refers to, such as filter = 12000 or filter = "Team base", and the ones those refer to, up to five levels: each one's JQL, read as you at the same moments and for the same check. For a filter referred to by name, the app first asks Jira for the names of the saved filters you can see whose names contain it, up to 250, and reads only the ones named exactly so

• when you open the gadget's settings, and again as you type in their filter box, the names of up to 50 saved filters you can see that match what is in the box, so that you can pick one. Nothing else about those filters is requested until you pick one, which is then read as the first item above describes

• the list of statuses in your site, and their categories. Jira sends each status with its description, its icon and, for a status that belongs to one project, which project; only the name and the category are used

• for each work item the filter matches that entered one of your Done statuses during the chart's range, or in the two days either side: its id, its key, its creation date, and its status change history — that is, which status it moved to and when

• when you open the gadget's settings, your own Jira profile's time zone, so the date range and the day boundaries default to the zone you already work in rather than to UTC. This is read only while the settings are open, it is read for the person configuring the gadget and nobody else, and the only field used is the time zone

• what Jira sends along with those reads, which the app does not ask for and cannot refuse:

  • Jira's change history records who made every change — their account id, display name, avatar, time zone and, depending on that person's Jira profile visibility settings, email address — and neither of the endpoints the app uses offers a way to leave it out.
  • A change record can also carry metadata written by the tool that made the change: the name, id, avatar and profile link of another person or system involved, free-text descriptions, and any other data that tool chose to attach.
  • When Jira does not allow the batch endpoint (see history read one work item at a time), the per-item endpoint has no filter at all, so Jira returns each work item's whole change history, including changes to fields such as the summary or the assignee.
  • The saved filter comes back with its owner — account id, display name and avatar — and with the groups, projects, roles and people it is shared with or editable by. It also carries its description, whether you and how many others have marked it a favourite, and when it was last used. So does every saved filter it refers to.
  • Your own profile comes back whole — account id, display name, avatar, locale and, depending on your profile visibility settings, email address — although only the time zone is used.

  In every case the app takes out the one thing it needs — the status changes, the filter's name and JQL, or the time zone — and discards everything else in memory as the response is read. Nothing it discards is stored, logged or sent anywhere. Of what it keeps, the status changes become the records listed below, the filter's name and the time zone are saved with the gadget's settings (also below), and the JQL is handed to the build and not stored by the app. The JQL of a filter it refers to is only checked, and that filter's name is shown in the settings when the check refuses it.

It reads nothing else. It does not request, and its Atlassian scopes do not permit, write access of any kind.

What the app stores

Only this:

What the app never stores

Summaries. Descriptions. Comments. Attachments. Custom field values. Assignees. Reporters. Changelog authors. Any Atlassian account id. Any name or email address of any person.

This is not a policy statement, it is a property of the code, and it is checked by an automated test on every commit: the test feeds the app work items carrying a summary, a description, a comment, an assignee display name, a reporter email address, an account id and a custom field, then asserts that none of those values appears in anything the app writes to storage or sends to analytics. The fields of every stored record are additionally allow-listed, so adding a new field to a stored record fails the build.

(The tests are packages/ports/test/privacy.test.ts, "the app stores no issue content and no user identity", which runs a build, and packages/app/test/resolvers.test.ts, "what the app stores", which runs every path that writes — a chart request, a build, a build Jira refuses, a queue that refuses the job, the drill panel and both exports — and checks every stored field and that no filter name, query or account id is kept in the app's own storage. Every other test in that file checks the fields of what it wrote, too.)

Who can see a chart

Before any chart, drill panel or export is served, the app checks — as you, using your own Jira permissions — that you can open the saved filter the gadget is built from. If you cannot open the filter, you are not served its data.

Please read this part carefully, because it is a real limitation.

A chart is computed once per configuration and shared by everyone who views that gadget. That is what makes it fast, and what makes two colleagues looking at the same dashboard see identical numbers. It also means the numbers cover every work item the saved filter returns that completed in the range, whoever is viewing — not a per-viewer subset of it.

So: the guarantee is per filter, not per work item. If you can open the filter, you can see the chart for all of it. If a filter spans a project that some viewers cannot browse, either put the gadget on a dashboard shared with the right people, or narrow the filter.

We would rather state this plainly than imply something stronger.

Where data lives

Inside your own Atlassian cloud instance. The app runs entirely on Atlassian Forge and stores its computed numbers in Atlassian's own storage, in the region Atlassian allocates to your site. The app operates no servers, no database and no infrastructure of its own. Apart from the product events described under Analytics, nothing it computes is copied to any system the app's author controls.

How long data is kept

• A computed chart is cached for 24 hours, then rebuilt on next use.
• A cached chart that has not been rebuilt for 30 days is deleted by a daily cleanup, together with the record of the build that produced it. The cleanup runs whether or not the site's licence is current, so a lapsed subscription does not leave data behind.
• On uninstall, the app can no longer run, and deletion is Atlassian's. Atlassian's storage documentation states that "Forge hosted storage retains data for 28 days after uninstallation", so that a reinstalled app can have its data re-linked on request; after that it is deleted.

Analytics

The app records four product events in a PostHog project hosted in the European Union:

• that a chart was built, with the number of work items it accounts for (those it charted and excluded together) as one of four bands (under 100, 100 to 999, 1,000 to 4,999, or 5,000 or more), and whether any history was missing or read the slow way;
• that a stored chart was shown on a dashboard;
• that the exclusion ledger was opened, and for which exclusion reason or for a mark on the chart;
• that a CSV was exported, and whether the whole ledger or the list in the panel.

Each event carries a salted SHA-256 hash of your site's cloud id and nothing else that could identify anyone. That hash identifies an installation, never a person. No Atlassian account id, no name, no email address, no issue key and no project name is ever sent. Automated tests check this against what is actually sent: packages/app/test/resolvers.test.ts ("what reaches the analytics processor") runs a build and every action that sends an event, and checks each event and property against the list above and each event's text for issue keys, the filter's name and query, and the cloud id; packages/ports/test/privacy.test.ts checks the build's event for the issue content described above.

Events are retained for 12 months.

Sub-processors

There are no others.

Support, and why it is written

Support for this app is written documentation and written correspondence only. There is no chat widget, no phone number, and no live support session — by design, not by omission. A written-only support channel is also a privacy property: nobody screen-shares your Jira instance to a stranger, and no support session ever grants a third party access to your data.

Contact

Write to hello@dwellchart.com. It is a written inbox, and it is the only support channel — see the section above for why that is deliberate. The same address is published on the app's Atlassian Marketplace listing.

For a question about your own data — what is held, or a request to delete it — say so in the subject line. Note that the app keeps no personal data of its own to return: everything in its own storage is derived from work item ids, keys and creation dates, status names and status timestamps, and it is deleted on the schedule above. The gadget's settings, including the configuring person's time zone, are kept by Jira with the gadget and go when the gadget is removed.

Changes

Material changes to this page will be noted on the app's Marketplace listing.