Documentation / OnTask

Data & privacy

Last updated: 18 September 2026

This page says what OnTask stores, where, for how long, who can see it and how it is deleted. Every number on it is one the code enforces. The policy that governs the relationship is the Privacy Policy; the technical statement is the Security & Sub-processor Statement; the contract for customers who need one is the Data Processing Agreement.

Where the app runs

OnTask is a Forge app. Its code runs on Atlassian's infrastructure and its data lives in Forge hosted storage on your own Atlassian site. Nothing runs on servers Soverain operates, because there are none.

No external network access

The app's manifest declares no external permission and no remote host. It cannot reach anything outside Atlassian: no analytics service, no error tracker, no AI provider, no content delivery network. Even the typefaces are bundled with the app rather than requested from a font service, so the running page makes no request to anyone but Atlassian. Atlassian checks that on every deployment, and has granted OnTask its Runs on Atlassian badge, which the Marketplace listing carries.

There is no model in the product. Ranking is a deterministic score computed on your site — see How the ranking works.

Permissions the app asks for

ScopeWhy
read:jira-workYour assigned issues and their comments and worklogs; the permission check before a manual entry; on the Team tab, the issues the people you picked logged work on, those issues' worklogs, and a check of whether you may browse users, so the people search can explain its results
write:jira-workThe worklog and the optional comment you confirm on the stop screen — nothing else, and never in the background
read:jira-userYour own profile — your timezone, and your name and avatar on the Team tab; whether an account still exists, for automatic erasure; on the Team tab, the people search and the names and avatars of the people you picked
storage:appThe running clock, your history, preferences and saved Team views
report:personal-dataAtlassian's Personal Data Reporting API, described below

Every call to Jira that reads or writes on your behalf is made as you, with your permissions. OnTask cannot see an issue you cannot see, and a worklog it writes is authored by you. The Team tab's calls are made from your browser, and they are made as you too.

The Team tab added no scope. It uses read:jira-work and read:jira-user, which OnTask already asked for. Every call it makes is a read, made from your browser as you:

CallScopeWhat it is for
POST /rest/api/3/search/jqlread:jira-workFind the issues the people you picked logged work on in the period
GET /rest/api/3/issue/{id}/worklogread:jira-workRead those issues' worklogs
GET /rest/api/3/mypermissions?permissions=USER_PICKERread:jira-workWhether you may browse users — asked once, so the people search can explain an empty result
GET /rest/api/3/myselfread:jira-userYour own account, name, avatar and the timezone the days follow
GET /rest/api/3/user/pickerread:jira-userThe people search behind Add people
GET /rest/api/3/user?accountId=read:jira-userThe name and avatar of someone you picked who logged no time in the period

What OnTask stores

DataWhat it containsKept for
The running clockThe issue key and summary, when it started, how long it has been pausedUntil you stop or discard it
Session historyFor each logged session: the issue key, the duration, and the summary you typed12 months
Submission recordThe record that stops one confirmation producing two worklogs: your account ID, the issue, the duration, the worklog's id30 days
Your preferencesOnly the settings you changed from their defaults — the comment default, the daily-total threshold, your ranking sliders — and which saved Team view you had openUntil you delete your data
Your saved Team viewsFor each view you save: its name, its period, and the account IDs of the people in it. Up to 50 people a view and 20 views. Only you can see themUntil you delete the view, your data is erased, or a site administrator deletes everyone's data. A person is taken out of every view when their data is erased, and a view left with nobody in it is deleted
Site settingWhether comments are allowed site-wide — not personal dataUntil deleted
Reporting bookkeepingWhen each account was last reported to Atlassian, which accounts are queued for erasure, and — if taking someone out of colleagues' saved views could not be finished when they deleted their data — a note to finish itKept while OnTask holds data for that account. Deleting a person's data removes their account ID here at once; an account OnTask stops holding for any other reason drops out when the next weekly report rebuilds this list. The note to finish a removal is deleted as soon as the removal succeeds

The personal data here is your Atlassian account ID, the summaries you wrote about your own work, and your saved Team views. The summaries are the part worth taking seriously: they are a per-person, timestamped record of what you worked on, in your own words. They are stored so the Today list can show them and so your history survives a reload. OnTask's own records about you — your running clock, your session history and the summaries you typed, your preferences and your saved views — are never shown to anyone else. Your ranked work and the score behind it are not shown to anyone else either, and they are not stored at all: OnTask works them out again each time it builds your list. The worklogs OnTask writes are ordinary Jira worklogs, though. Their issue and duration can appear on a colleague's Team tab, like any other worklog they can see. The worklog comment, which may hold your summary, is never shown there.

Saved views hold other people's account IDs. They can include colleagues who have never used OnTask, and a view's name is text you typed.

A month of session history is capped at 400 entries, so it cannot grow without bound.

One detail about preferences. A preferences record saved by an earlier version of OnTask still holds a copy of every default, written the first time that person saved anything. It keeps that copy until OnTask next saves that person's preferences — when they change a setting, or open a saved Team view — and then holds only what they changed. Until then, a stored value that equals the current default is ignored when the record is read, so you follow the current default either way.

A daily job enforces the retention periods above. It can read Jira — to ask whether an account still exists — but it is structurally unable to write to Jira.

What it does not store

  • No display names or avatars, and no other profile data. Every name and picture OnTask shows — the person who mentioned you, who a comment will notify, your greeting, the people on the Team tab and in its people search — is read from Jira for that one response or that one page, shown, and never stored. Nothing persisted holds a copy of anyone's profile.
  • No one's logged time. The Team tab adds up worklogs in your browser each time it loads and throws the result away. OnTask keeps no copy of anyone's hours.
  • No analytics, no telemetry. Log lines carry counts and durations only — never a storage key, a stored value, an account ID or a raw error. Nothing is logged about whose time you look at.

The Team tab

The Team tab shows how much time the people you pick logged in Jira, per day, over a period you choose. It is on for every site that has OnTask, and anyone with OnTask on the site can open it. OnTask has no setting to turn it off. There is no manager role and no privileged view. Everyone opens the same tab, and each person sees only what their own Jira permissions already allow. How to use it is in Team timesheet.

What it does:

  • It reads Jira worklogs, however they were logged — through OnTask, in Jira itself or by another app — and adds them up per person, per day and per issue.
  • It reads them in your browser, as you. You see only worklogs on issues you can already open in Jira, and only worklogs whose visibility Jira allows you. It gathers into one place what Jira already lets you see; it does not open up anything new.

What it does not do:

  • It does not store the figures. They are worked out on each load and discarded.
  • It never shows a worklog's comment. It shows issue keys, issue summaries and durations.
  • It does not show OnTask's own records about a person: their running clock, their session history and the summaries they typed, their preferences or their saved views. It does not show how OnTask ranks their work, or the score behind it. Time they logged through OnTask can still appear, because it is a Jira worklog; its comment does not.
  • It does not log whose time was viewed, and it does not tell a person that someone looked.
  • It does not score or judge anyone. People appear in the order they were added.
  • It cannot quietly bring back someone who deleted their data. If a saved view changed while someone had it open, saving over it is refused: the view is reloaded, without the person who left it, and the tab asks them to check it and try again.

If you run a Jira site, one part of this is yours. Your organisation is the controller of this data. Looking at colleagues' logged time is workplace monitoring. Your organisation needs a lawful basis for it, and must tell its staff where the law requires it. OnTask cannot make that call for you.

What it writes into Jira

Two things, both authored by you and both shown to you before they happen: a worklog — duration, start time, and your summary as its comment if you leave that switch on — and, only when you tick it, an issue comment containing your summary exactly as typed, plus the duration and the issue key. See The clock & worklogs.

Those become ordinary Jira data. They are yours, they live in Jira's own history, and — this matters for the next section — deleting your OnTask data does not delete them.

Personal Data Reporting

Because OnTask stores account IDs, it implements Atlassian's Personal Data Reporting API.

Once a week, OnTask reports the account IDs it holds to Atlassian, including the people inside saved Team views, those reported longest ago first. A run has a time limit, because the job it runs in does; on a very large site, the accounts it does not reach lead the next week's run, so some are reported every second week rather than every week. Atlassian answers with the accounts that have since been closed, and a daily job erases those people's data. An erased person is also removed from every saved view, and a view left with nobody in it is deleted. A view's name is its owner's own text, so OnTask does not change it. An erasure that fails stays queued and is retried; it is never silently dropped. Accounts whose data has already gone are dropped from the bookkeeping — keeping the ID would mean holding personal data about someone whose data was already erased.

Atlassian can also answer that a profile was updated. OnTask deliberately does nothing with that, because it holds no copy of any profile to refresh.

Neither job is switched off when a subscription lapses. A privacy obligation holds regardless of billing.

Deletion

WhoHowWhat happens
YouSettings & privacy → Delete my OnTask dataEverything above that is yours — clock, history, preferences, saved views — is erased, you are removed from any view someone else saved, and your account ID leaves the reporting bookkeeping at the same time. If taking you out of someone's view cannot be finished then and there, OnTask notes it and retries in its daily run until it is done. No admin needed; it is your own data
A site administratorSettings & privacy → Delete everyone'sEvery OnTask record on the site is erased. The button is shown only to admins and the check is repeated on the server, so it cannot be reached by hiding the button
A closed accountAutomaticReported weekly, erased daily, as above, including from other people's saved views. A bounded check of each stored account also runs as a backstop
RetentionAutomatic, dailyThe periods in the table above

Neither deletion is refused when a subscription has lapsed — but only Delete my OnTask data is reachable then, on the lock screen that replaces the app. Delete everyone's is in Settings & privacy, behind that screen; a site administrator who needs it while the subscription is lapsed should write to support@soverain.cz. Nor does either touch the worklogs and comments already in Jira — those are the customer's own Jira data, authored by their own users, and are not the app's to remove.

Uninstall

When a site uninstalls OnTask, Atlassian deletes the app's hosted storage under its own Forge policy: a soft delete, then disposal, with a retention window during which a reinstall can be relinked to the previous data. OnTask deliberately does not race that with a wipe of its own — Atlassian's mechanism is the reliable one, and an eager wipe would destroy the relink option customers are entitled to. Anyone who wants their data gone before uninstalling has the delete buttons above.

Sub-processors and residency

OnTask has no sub-processors of its own. Everything it stores sits in Forge hosted storage operated by Atlassian as part of your site — the same position as the rest of your Jira data. Sub-processors are listed in the Security Statement.

It stores nothing outside Forge hosted storage, so it inherits whatever residency your Atlassian site has. There is no second location to pin.

Related