Privacy policy — Outlier

This page is written from the architecture, not from a template. The source is not public, but two things are checkable without it. The method page prints the whole arithmetic. The app's Forge manifest is shown to you by Atlassian before you install, and it either declares an external host or does not.

Last reviewed: 2026-11-01.

This is version 5. The app has not changed since version 4; this site has: it now has a support form, and this edition says what the form sends and the check that runs before it does: The support form. See Changes.

At a glance#

• Your Jira sitethree fields per ticket and its changelog, for the boards a gadget watches. Read on the app's own schedule as the app, and each time a card is drawn or a rule asks for it, as that person.
• Outlier, inside Atlassiankeeps when each ticket entered and left each status, in Forge storage on your own site. The rest of the changelog is discarded where it arrives.
• The vendorthe contact details on a paid licence, from Atlassian, and whatever you write to support. Application logs of counts, durations and field names. Ten of the app's logging statements name a card or its board, and a failed request to Jira is logged with the ids in its path. Never ticket content, as the security page sets out.
• Anywhere elsenothing. The manifest declares no external domain, no remote and no outbound fetch.

Every record the app keeps, and how long it lives, is in one table under How long it is kept. Uninstalling the app deletes its rows, with one exception for a board too large to finish.

Contact: support@chmut.com.

Who this covers#

Outlier is a Jira dashboard gadget built on Atlassian Forge. It is distributed through the Atlassian Marketplace. It runs inside Atlassian's infrastructure. It has no servers, no database and no backend of its own.

The vendor is Oleksandr Chmut, a sole trader registered in Ukraine, trading as oc, and the vendor on the Marketplace listing. For a support message that covers the message, the address it came from, and whatever the sender chose to put in it.

This site is covered too. outlier.chmut.com is a set of pages — this policy, the method, the security page, pricing and the rest — and Cloudflare serves every one of them. A request that fetched one is a request to a server somewhere, and the vendor is the controller for that too. Cookies and tracking says exactly what is collected.

The basis for processing#

A support message is not used for anything else. There is no marketing, no profiling, no list, and nowhere it is sent. Sub-processors says what is done with the licence contacts.

What the app reads#

From Jira, as the app or as the person looking, depending on the request.

Collection runs on a schedule of the app's own, not when somebody looks at a dashboard. So processing happens without a person present, for the boards that are being watched, and only those.

The card reads Jira too. Each time it is drawn, or an Automation rule asks for its morning, it reads the work in flight again, as the person looking or the person whose rule it is. That read writes no row per ticket. What it keeps is the two rows per card, when the board was last looked at and whether it still means what the gadget was set up against in the board's rows, and the day it rendered in the installation's row.

What is used, and what is dropped#

Stated precisely, because it is the claim a security review will test.

• Jira's changelog endpoint has no field filter. The response therefore does carry the old and new text of summary and description edits, and the name of whoever made each change.
• All of it is discarded at the boundary. Nothing derived from it is computed and nothing derived from it is written anywhere.

The honest sentence is "the app reads only how tickets moved", not "content is never sent to us". The second would be easy to disprove with a proxy. The first survives being checked.

What it asks for#

The list an administrator approves at installation. That screen is the first thing a security review looks at, so this page is not silent about it.

read:board-scope:jira-software
read:board-scope.admin:jira-software
read:project:jira
read:sprint:jira-software
read:filter:jira
read:jql:jira
read:status:jira
read:project-role:jira
read:application-role:jira
read:avatar:jira
storage:app
read:issue-details:jira
read:issue-meta:jira
read:issue.changelog:jira
read:issue-type-hierarchy:jira
read:field:jira
read:field.default-value:jira
read:field.option:jira
read:field-configuration:jira
read:audit-log:jira
read:user:jira
read:group:jira

• Every entry that reads Jira is read-only. The app has no write scope of any kind.
• storage:app is the one that is not a read. It is the permission to keep anything at all. What the app stores is entirely about what it allows.
• The list is longer than the single read:jira-work most gadgets ask for, on purpose. That one line grants comments, attachments, worklogs and the whole of every issue. It would have put "we never read the content of your tickets" beside a permission granting exactly that.

Most of the list is one endpoint's price.

The first two rows are there because they look wrong on the screen: an avatar and an audit log, in a gadget that reads three fields. Printing the list makes the shape of the request checkable against Jira's own documentation rather than against our word.

What the app stores#

In Atlassian Forge storage, on your own site. Nothing anywhere else.

Per ticket#

One row per ticket: when it entered and left each status, and whether it is resolved. A resolved ticket's row lives 400 days from the day it closed; an unresolved one has no age limit while a board on the site holds it. When a board is forgotten, the rows of its tickets that no other board holds go with it.

Per column#

Counts and durations per column, derived from the ticket rows, with the status names and no ticket key. Kept while the board is read; a month of finished stays older than 360 days goes sooner.

Per site#

The list of status ids and names your Jira defines, the same list any user of your site can see. Kept until the app is uninstalled.

Per board#

Three rows for each board a gadget points at: its settings, how it was last read, and how far the walk through its history has got. All three live while the board is read. The labels a gadget is narrowed by are kept, and they are text a person wrote; the query is not. The record of the last read can name a ticket key, when the read failed on one.

Per card#

Two rows for each card, both written when the card is drawn or a rule asks for it: what the card last said, and its last 60 mornings as counts per age. Both live while the board is read.

Per installation#

Three rows, each one for the whole site and none about a board: the days a card rendered in its first thirty days here, where deletion last stopped, and how far the check of ticket rows after a forgotten board has got.

No per-person field#

No per-person field, anywhere. Not assignee, not reporter, not the account id of whoever moved a ticket. This is enforced by a check that refuses such a field at the boundary, not by intention.

That is a claim about fields. A check that refuses a column called assignee cannot read inside a string somebody else wrote. The query is not kept, so there is no such string for a name to be buried in. What is kept about a board is identifiers and the labels your team chose.

When a board stops being read#

The per-ticket rows are not the board's. A ticket two boards hold has one row, so the rows of a forgotten board's tickets go once the hourly sweep finds that no board left on the site holds them. Per ticket says how.

A board too large to delete in the time the platform allows is reported, not silently half-deleted. The run records what it could not finish. Forge's own 28-day window then removes whatever is left. So the outcome is the platform's default, not an indefinite remainder.

It is the one path here where deletion is not immediate. Write to the address above if you need it confirmed for a particular site.

What the app never does#

• Send anything to any host other than your own Atlassian site. There is no analytics endpoint, no vendor backend and no third-party service. The manifest declares no external domain, no remote and no outbound fetch, and Atlassian has granted the app its Runs on Atlassian badge on that basis: it is under Trust signals on the listing. The manifest itself is what Atlassian shows you before you install.
• Send anything to a language model from the pipeline. Every number on the card is arithmetic and every sentence is written. Nothing is generated, and the product works unchanged for a site with no AI of any kind.
• Produce any output about an individual person. Nothing in collection decides anything about a person. There is no profiling, no scoring and no automated decision with a legal or similarly significant effect, because there is no per-person output for one to be made from.

Ask Rovo why#

One control is the exception to the second of those.

• Where: only where your site has Rovo, and only if the platform says the person reading has it.
• When: only when you press it.
• What it opens: your Rovo, in your own instance, under your own permissions and on your own credits.
• The question: the card's text, the same text the copy button puts on your clipboard. With it, the ticket keys the card counted rather than listed, one sentence saying what an Outlier card is, and the request itself.
• Nothing new in it: no kind of data the card does not already show you. Ticket keys, column names, and how long work has been waiting.
• The answer: goes to you. We never see it, and nothing about it comes back to us.
• No model of ours: none is deployed by this app, and none is called on its behalf.

How long it is kept#

Each record's lifetime is set out in its own section above. This table is the index.

Cookies and tracking#

The gadget: none. No cookies, no tracking pixel, no analytics script, and nothing loaded from any host.

This site is not the gadget. It loads one analytics script on every page and, on the support page alone, Cloudflare's check that a person is sending the form. All of it is listed here.

• Cloudflare serves it, and sees each request that fetched a page.
• Cloudflare Web Analytics is a script that sets no cookie and identifies no visitor. For each page fetched it records the page, the page that linked to it, the visitor's country, the kind of device, the browser and operating system, how the page was reached, and how quickly it loaded and responded. The vendor sees those as totals and averages.
• Cloudflare Turnstile runs on the support page and nowhere else. Before the form sends, it reads signals from the browser and the connection, the IP address among them, to tell a person from a script, and gives the form a token saying which. What Cloudflare does with those signals is set by its own terms for Turnstile.
• One script of our own handles layout and keyboard reach. It fetches nothing, stores nothing, and sets nothing that outlives the tab.

Every page runs one script of our own — 256 lines, comments included.

The support form#

The support page has a form. It is another way to write to support@chmut.com, not a different thing.

• What it sends: the address you type, your name if you type one, and the message. Nothing about you is added to them: not the page that led you to the form, not your IP address. What is kept beside them is the time it arrived and which product's form it came through.
• The route: the form posts to a Cloudflare Worker at this site's own address. The Worker asks Turnstile whether the token is valid and was issued for this site, passing your IP address along with the token, and nowhere else. It then keeps the message in a Cloudflare D1 database held in the European Union, where support reads it. If it cannot keep it, its log says why and does not name the sender.
• Kept for 30 days, answered or not, and then deleted by a daily sweep. A request to support@chmut.com has it deleted sooner.
• The answer comes from support@chmut.com, so from there the exchange is support correspondence like any other, and kept as long as that is.

Where it is held#

In your own Atlassian site's Forge storage, in the realm your site is pinned to.

• Outlier stores in-scope end-user data exclusively in Forge hosted storage. It declares no external domain, no remote and no outbound fetch.
• So Atlassian handles hosting, pinning and migration between realms. The app is shown as PINNED in an administrator's data residency view.
• If you migrate your site to another realm, the app's data migrates with it.

Residency covers where data is stored, not where it runs. Atlassian's documentation notes that Forge "may sometimes execute an app's invocation from a location other than the location where the host Atlassian app is". Where a given invocation runs is Atlassian's to decide. In every case it is Atlassian's own infrastructure. Nothing in this app reaches any other host.

Sub-processors#

None for the app. Nothing it reads leaves your Atlassian site, so there is no third party to name: no analytics, no vendor backend, no model, no host of ours anywhere in the path.

Three exist around it. "None" without them would be true only of the half a reader is not asking about.

The licence contacts are never joined to anything read from a board. There is nothing to join them to: no record the app stores names a person.

None of the three touches Jira data. All three are listed so the answer stays true when somebody checks it, not only when it was written.

Your rights#

The ticket data stays inside your own Atlassian site. Your agreement with Atlassian covers the platform holding it. It does not cover this app, which is a third party to it. Uninstalling the app deletes what it stored, with the one exception: a board too large to finish inside the time the platform allows leaves a remainder, which the platform's own 28-day window then removes.

For a support message:

• You can object to it being kept at all. The basis is legitimate interest, so an objection is a right rather than a request. The answer is deletion unless the exchange is still open.
• You can ask to restrict processing while a question about it is being settled, at the same address.
• It is deleted after 24 months, or sooner on request. A figure rather than a criterion: "as long as needed to answer a follow-up" is unauditable, and a mailbox with no rule in it is a mailbox that keeps everything.
• Portability does not apply to any of it. The right covers data processed on consent or on a contract. Everything the vendor controls here rests on legitimate interest. It is said here because a list of rights that names five and skips one reads as an oversight.

If you are in the EU or the UK and believe either has been handled wrongly, you can complain to your national supervisory authority. You are not required to raise it with us first, though we would rather you did.

Changes#

Version 5 adds the support form: what it sends, the check that runs before it does, and the 30 days Cloudflare keeps it for. The app has not changed since version 4, and neither has what is kept from support correspondence or for how long.

It takes effect at once rather than after thirty days' notice. It covers only a message you choose to send through the form, which did not exist before, so nothing already collected goes anywhere new.

Version 4 is the first edition laid out for reference. It names records the earlier editions left out, and corrects one place where they were wrong, both set out below.

The app changed once since version 3. Every edition said that what was kept for a board nobody reads is deleted after 90 days. Until this edition took effect, the app kept an open ticket's row for as long as any other board on the site was read, because two boards that hold a ticket share its row. It now checks each such row against the boards left and deletes the ones none of them holds: Per ticket. That was a fault in the app, not in the editions, and the fix makes it keep less, not more. So it takes effect without the thirty days' notice below, which is owed for keeping more or for longer.

Every earlier edition is published below with its own digest. All of them change together, so a reader who kept a copy can tell whether they are holding the current one.

The method has been versioned from the beginning. It would be strange to hold the arithmetic to a rule the policy about your data was not held to.

This edition#